UUID Generator — Free Online Tool on Toolpile
Every tool you need, one place
PDF, Image, AI, Dev, and Business tools — free, private, no signup.
Toolpile uses cookies for analytics and ads. The tools themselves keep your files in the browser — that doesn't change. Read the full policy
PDF, Image, AI, Dev, and Business tools — free, private, no signup.
About UUID Generator
A UUID (or GUID — same thing, different vendor) is a 128-bit identifier designed so two systems can generate IDs without coordinating and almost certainly never collide. "Almost certainly" hides a lot of math — and the choice between UUIDv4, v7, and the older versions actually matters for things like database performance and sortability. This tool generates them; what follows is when each version is right.
A UUID is 128 bits, displayed as 32 hex digits in the canonical 8-4-4-4-12 grouping: `f47ac10b-58cc-4372-a567-0e02b2c3d479`. The hyphens are cosmetic — the underlying value is just 128 bits. The format is defined in RFC 4122 (2005) and updated in RFC 9562 (2024) which added v6, v7, and v8.
128 bits gives 2¹²⁸ ≈ 3.4 × 10³⁸ possible values. The famous "birthday paradox" math says you'd need to generate roughly 2.7 × 10¹⁸ random UUIDs before having a 50% chance of one collision. At a million UUIDs per second on every device on Earth, that takes about 100 years. For practical purposes, randomly-generated UUIDs don't collide.
The point of the format isn't the size — it's the decentralisation. Any process anywhere can generate a UUID without asking a central authority, without coordinating with any other process, and the chance of collision is negligible. That's what makes them useful for distributed systems: every database row, every event, every uploaded file gets its own ID without a sequence-number bottleneck.
**UUIDv1** (timestamp + MAC address). Generated from the current time + the machine's network MAC address. Sortable by creation time; leaks the MAC address (fixed in v6 by reordering bits). Rarely used in 2026 except in legacy systems — the privacy concerns and the random-fragmentation behaviour in databases pushed everyone toward v4 for a decade, then to v7 once it was standardised.
**UUIDv4** (random). 122 bits of pure randomness (6 bits encode the version + variant). The default that most languages produce when you ask for "a UUID". Maximum collision resistance, zero information leak, but completely unsortable — two UUIDs generated a millisecond apart look unrelated. This is the cause of the famous "v4 hurts B-tree index performance" problem in databases: every insert lands in a random spot in the index, fragmenting it.
**UUIDv7** (timestamp + random) is the 2024 standard for new applications. The first 48 bits are a Unix millisecond timestamp; the rest is random. UUIDs generated in sequence sort in time order. Still 74 bits of randomness, so collision-resistance is fine. And because new UUIDs always sort to the end of an index, B-tree performance matches what you'd get from an auto-increment integer ID. If you're building anything new in 2025+ and your database stores UUIDs, use v7. The major language libraries (Node uuid v9+, Python uuid v6+, Java JDK 21+) all support it.
Versions 2, 3, 5, 6, 8 exist but are special-purpose. v3 and v5 are deterministic UUIDs derived from a name (useful for stable IDs from a known string — namespacing). v6 is v1 reordered for sortability without the privacy fix of v7. v2 is essentially never used. v8 is custom format space for application-defined schemes.
UUIDs feel free but cost more than people realise. **Storage**: 16 bytes per UUID (or 36 bytes if stored as text — most ORMs do this by default). An auto-increment integer is 4-8 bytes. For a table with billions of rows, that's gigabytes of difference plus index size.
**URL aesthetics**: `/users/f47ac10b-58cc-4372-a567-0e02b2c3d479/profile` is uglier than `/users/abc123/profile` and harder for users to share verbally. If users will see or type the ID, a shorter scheme (Stripe-style `cus_abc123`, NanoID, ksuid) is friendlier. Behind-the-scenes IDs that users never see — UUID is fine.
**Security identifiers**: UUIDs are not secrets. v4 is unguessable (122 bits of entropy), so it's resistant to brute-force enumeration — but that's not the same as cryptographic security. Don't use a UUID as a password reset token, API key, or session identifier without explicitly treating it as a secret (storing it hashed, expiring it, transmitting only over TLS). For tokens, dedicated random strings from a CSPRNG are clearer.
**Cross-system primary keys at petabyte scale**: even UUIDv7's small randomness collision risk becomes meaningful at extreme scale. Companies like Twitter (Snowflake IDs), Discord (Snowflake variants), and Stripe (custom prefixed IDs) build their own. For 99.9% of applications, a UUID is fine.
Are UUIDs guaranteed unique?
Not guaranteed — astronomically unlikely to collide. The math: with 122 bits of randomness in v4, you'd generate ~2.7 quintillion UUIDs before a 50% collision chance. For any normal application, treat UUIDs as effectively unique. Use a database UNIQUE constraint anyway as a belt-and-suspenders check.
What's the difference between UUID and GUID?
Nothing. GUID ("Globally Unique Identifier") is Microsoft's name for UUID. Same 128-bit format, same RFC 4122 spec, same canonical text representation. GUIDs from .NET work in any UUID-aware system and vice versa. Just call it UUID; "GUID" is a Microsoft regionalism.
Should I use UUIDv4 or UUIDv7 for a new project?
v7 if your database stores it as a primary key — sortable inserts mean B-tree indexes don't fragment, and that translates to measurably faster bulk-insert performance. v4 if you specifically don't want a timestamp embedded in the ID (privacy, security, leaking creation order) or if your environment doesn't support v7 yet. For standalone IDs (cache keys, request tracing, file names), either works.
Can I shorten a UUID for URLs?
Yes — encode the 16 binary bytes as Base64 (22 characters with padding stripped) or Base58 (~22 characters, no ambiguous chars). Both are URL-safer than hex and 33% shorter. Some teams use NanoID instead — a custom 21-character format that achieves the same collision resistance with friendlier characters. Pick based on whether the ID will be shown to users (NanoID) or stays internal (UUID hex is fine).
Why do my UUIDs from different libraries look slightly different?
All UUID libraries produce the same canonical 8-4-4-4-12 hex format. Differences are usually case (some lowercase, some uppercase — both valid) or wrapping (some libraries return `{f47ac10b-...}` with curly braces, the .NET convention; strip the braces for cross-system use). The underlying 16 bytes are identical.