Free UUID Generator

A Universally Unique Identifier, What and Why

A UUID (Universally Unique Identifier) is a 128-bit identifier designed to be unique across space and time without coordination between the parties generating them. The format is 8-4-4-4-12 hexadecimal characters with hyphens, for example, 550e8400-e29b-41d4-a716-446655440000. Two reserved bits identify the variant and four bits identify the version, leaving up to 122 bits available for randomness or for encoded data depending on the version. UUIDs make it possible to generate identifiers in completely separate processes (different services, different machines, different continents, different decades) with effectively no risk of collision. That property is exactly what distributed systems need: a primary key for a new database row that doesn't require asking a central counter; a correlation ID for an HTTP request that doesn't need a shared sequence; a file name that won't collide with names generated independently elsewhere. This generator uses crypto.randomUUID() (with a crypto.getRandomValues() fallback for older browsers) to produce cryptographically random UUIDs entirely in your browser, with no upload anywhere.

A Four-Decade History, From Apollo to RFC 9562

The UUID concept originated in the Apollo Network Computing System (NCS) in the mid-1980s, designed at Apollo Computer by Paul Leach and Rich Salz to support distributed computing without central registration. The format was adopted by the Open Software Foundation Distributed Computing Environment (OSF DCE) at the start of the 1990s and later standardised by ITU-T as X.667 / ISO/IEC 9834-8 (first issued 2004, current edition 2012). The IETF folded the spec into RFC 4122 (Leach, Mealling, Salz) in July 2005, which became the canonical reference for two decades. RFC 4122 was updated by RFC 9562 in May 2024, which kept all the original versions (v1 through v5), added three new versions (v6, v7, v8), and formally defined the special "Nil UUID" (all zeros) and "Max UUID" (all ones) constants. The versioning lineage matters because each version trades different properties: time-based (sortable, leaky); name-based (deterministic from inputs); random (universal, opaque); custom (whatever you need). Modern best practice for new applications has shifted from v4 (random) to v7 (timestamp + random) for primary keys, while v4 remains the right answer for opaque identifiers where sortability is undesirable.

The Eight Versions, In Plain English

• v1 (timestamp + MAC address). 60 bits of timestamp (100-nanosecond intervals since 1582 Gregorian epoch) plus the originating machine's MAC address. The major drawback: it leaks the MAC address of the generating machine, which is a privacy concern. The Melissa virus author was famously identified in 1999 partly by tracing v1 UUIDs in Word documents back to a specific machine.
• v2 (DCE security). Variant of v1 that includes a POSIX UID/GID. Almost never used in practice; documented for completeness.
• v3 (name-based, MD5). Deterministic UUID derived from the MD5 hash of (namespace UUID + name string). Same inputs always produce the same UUID, useful for translating natural keys (URLs, domain names, distinguished names) into UUID form.
• v4 (random). 122 bits of randomness (the remaining 6 bits are version + variant tags). The most widely used version, the default that nearly every "give me a UUID" library returns.
• v5 (name-based, SHA-1). Same as v3 but using SHA-1 instead of MD5. Preferred over v3 for new applications because SHA-1 is less broken than MD5, even though both have known collision attacks.
• v6 (RFC 9562, May 2024, time-ordered). Re-orders the v1 timestamp bits so that lexicographic sort matches chronological sort. Solves the "v1 doesn't sort by time" complaint; RFC 9562 recommends populating the bottom 62 bits with random data rather than a real MAC, so a properly-generated v6 does not leak machine identity.
• v7 (RFC 9562, May 2024, Unix timestamp + random). The first 48 bits are the Unix timestamp in milliseconds; the remaining 74 bits are random. Sorts naturally by creation time, includes timestamp data without leaking machine identity, and is the modern recommendation for database primary keys. Postgres ships gen_random_uuid() for v4 since version 13 and has community v7 implementations available as functions or extensions; SQL Server has NEWSEQUENTIALID() with similar properties.
• v8 (custom). Reserved for application-specific layouts. The version field marks it as v8 and the variant bits are set correctly; everything else is up to the application. Use when you need to embed your own structured data into the UUID-shaped envelope.

Why v7 Is Increasingly Preferred Over v4 for Database Keys

Random primary keys (v4 UUIDs) have a well-documented performance cost in databases that organise rows by primary key in a B-tree or similar index. Each new insert lands at a random position in the index, which fragments the index pages, increases write amplification on disk, and trashes the page cache because rows that were recently inserted are scattered across many pages instead of clustered together. Sequential keys (auto-incrementing integers, ULIDs, v7 UUIDs) all insert at the rightmost edge of the index, which keeps the working set small and write amplification minimal. The "random key anti-pattern" critique goes back to early SQL Server documentation around NEWID versus NEWSEQUENTIALID, and has been re-articulated by the Postgres community for v4 vs v7. The trade-off: v7 leaks the creation time of every row, which can be a privacy or information-leakage concern in some applications (e.g. you can tell when an account was created by reading its UUID). For most applications the performance win outweighs the timestamp leak; for high-privacy applications, v4 remains the right answer.

Collision Probability, The Birthday-Paradox Math

UUID v4 has 122 bits of randomness, giving approximately 5.3 × 10³⁶ possible values. The birthday paradox says you need roughly √(2N·ln 2) draws (around 1.18 × √N) to have a 50% chance of any collision, which works out to about 2.71 × 10¹⁸ UUIDs. To put that in human terms: if you generate 1 billion UUIDs per second continuously, you would need about 86 years to have a 50% chance of a single collision. For ordinary application-scale generation rates (thousands or millions per day), the practical collision risk is zero. The most likely cause of "duplicate UUIDs" in real systems is a buggy generator using Math.random() instead of a CSPRNG, or a generator with insufficient entropy at startup, or a process that accidentally seeds two generators identically, not the underlying mathematics. This generator uses the browser's crypto.randomUUID() (where available) or crypto.getRandomValues(), both of which draw from the operating system's CSPRNG (Linux getrandom(), Windows BCryptGenRandom, macOS SecRandomCopyBytes), the same entropy source used for TLS session keys.

Browser Implementation: crypto.randomUUID()

The Web Crypto API exposes crypto.randomUUID() as a one-call generator that returns an RFC 4122-compliant v4 UUID string. It shipped in Chrome 92 (July 2021), Firefox 95 (December 2021) and Safari 15.4 (March 2022), and has been baseline-available in all modern browsers since approximately 2022. For older browsers, the standard fallback is to allocate a 16-byte Uint8Array, fill it with crypto.getRandomValues(), set the version nibble to 4 (the 7th byte's high nibble = 0x40), set the variant bits to 10xxxxxx (the 9th byte's high two bits = 0x80), and format the bytes as the 8-4-4-4-12 hex string. This generator uses crypto.randomUUID() when present and the manual fallback otherwise, the output is identical either way, just slightly slower on the fallback path. Both paths run entirely in your browser; nothing crosses the network.

Use Cases, and What Each Actually Needs

• Database primary keys: especially distributed or sharded systems where coordinating an integer counter is impractical. v7 is the modern recommendation; v4 if you need timestamp opacity.
• API request correlation IDs. Every incoming request gets a UUID that travels through every downstream service in the call chain; logs from any service can be tied back to the originating request via the ID. Stripe, Twilio and AWS X-Ray all do this.
• Idempotency keys for HTTP requests. Stripe's Idempotency-Key header takes a UUID; if the client retries the same request with the same key, Stripe returns the cached response instead of charging the card twice. This pattern is now standard across payment APIs.
• Session tokens, with caveats. A v4 UUID is cryptographically random and has 122 bits of entropy, which is more than enough for a session ID. But session tokens that are only a UUID are vulnerable to enumeration attacks if any related endpoint leaks them; the modern best practice is to use longer, signed tokens (JWTs, Paseto) for session state.
• File names for upload deduplication. Generate a UUID for each upload, store the file at /uploads/{uuid}.ext: you'll never have a name collision regardless of the original filename, and you can't accidentally serve another user's file by guessing the URL.
• Message IDs in event-driven systems. Kafka, RabbitMQ, AWS SQS and most pub/sub platforms recommend a UUID per message for tracing and deduplication; v7 is increasingly the default for the timestamp-sortable property.
• Test data generation. Faker libraries in every language use UUIDs as default IDs for generated test rows.
• Distributed system node identifiers. A new node coming up in a cluster generates a UUID for itself; the cluster coordinator uses that ID to route traffic and identify the node in logs.

Alternatives Worth Knowing About

UUID is the universal default but not the only option, and several alternatives are worth knowing for specific use cases. ULID (Universally Unique Lexicographically Sortable Identifier, Alex Knol, ~2016): 128 bits like UUID, but encoded as 26 Crockford-Base32 characters instead of 32 hex digits, more compact and case-insensitively URL-safe. The first 48 bits are a Unix millisecond timestamp, so ULIDs sort lexicographically by creation time. Conceptually very close to UUID v7, predating it by years. Snowflake (Twitter, 2010): 64 bits, much smaller than UUID, fits in a SQL BIGINT. 41 bits of timestamp + 10 bits of machine ID + 12 bits of per-millisecond sequence. Used by Twitter/X, Discord, Instagram, and many at-scale systems where 64-bit primary keys are a hard constraint. KSUID (Segment, 2017): 27 characters, second-precision timestamp + 128 bits of random. Trades millisecond precision for a smaller string representation than UUID. nanoid (Andrey Sitnik, 2017): a tiny library that produces random URL-safe identifiers of configurable length. Default 21 characters provides similar collision resistance to UUID v4 in many fewer bytes. For a public-facing URL where you'd otherwise embed a UUID, nanoid is shorter and friendlier. The trade-off: nanoid identifiers don't have the version + variant marker bits that distinguish them as UUIDs, so they don't slot into systems that expect UUID-shaped values.

URL Safety and Format Variations

UUIDs in their canonical hyphenated form (550e8400-e29b-41d4-a716-446655440000) are URL-safe, every character (lowercase letters, digits, hyphens) is in the unreserved set defined by RFC 3986. This means you can drop a UUID directly into a URL path or query string without percent-encoding. Some systems strip the hyphens for compactness, producing a 32-character hex string (550e8400e29b41d4a716446655440000) that's still URL-safe; the conversion is reversible because UUID structure is fixed. A few systems wrap UUIDs in braces ({550e8400-e29b-41d4-a716-446655440000}), Microsoft's GUID convention; the braces are decorative and never travel in URLs. Some systems uppercase the hex characters; UUIDs are case-insensitive per the spec, but consistency within a system matters. This generator offers all three options (uppercase, braces, no dashes) for compatibility with whatever pipeline you're feeding the UUIDs into.

UUID vs GUID, Same Thing, Different Name

UUID is the standard term used by IETF, ISO and most open-source projects. GUID (Globally Unique Identifier) is the Microsoft term used in Windows, .NET, COM/OLE, SQL Server, Active Directory and the Windows Registry. Both refer to the identical 128-bit identifier in the same 8-4-4-4-12 hex format. Functionally interchangeable, a GUID generated by Windows can be used anywhere a UUID is expected, and vice versa. The differences worth knowing are byte-order details inside the binary representation: Microsoft's classic GUID layout stores the first three fields little-endian rather than big-endian, which is why a binary GUID and a binary RFC UUID with the same logical value will print to different hex strings unless the reader handles the swap. If you receive a GUID from a Microsoft-origin system and want to know which version it is, check the version nibble (the 13th hex character, '1' for v1, '4' for v4, etc.).

Privacy: Why Browser-Only Matters Even Here

A UUID has no inherent meaning, so why does it matter that the generator runs locally? Two reasons. First, when a UUID is used as a session token, an idempotency key or any other secret-like identifier, generating it on a third-party server means that server saw the value before you used it, a small but real exposure. Second, server-side generators that promise "cryptographic randomness" cannot be verified by the user; a buggy or malicious server could return non-random values that look random, and you'd have no way to detect the bias. A browser-only generator runs the same crypto.randomUUID() call your application would run server-side; the entropy comes from the same operating system source (Linux getrandom(), Windows BCryptGenRandom, macOS SecRandomCopyBytes); no third party sees the output. You can verify by opening DevTools' Network tab while you click Generate, there are no outbound requests. Take the page offline (airplane mode) after it loads and the generator still works.

Frequently Asked Questions

What is the difference between UUID and GUID?

Same thing, different name. UUID is the standard term used by IETF (RFC 4122 / RFC 9562), ISO (ISO/IEC 9834-8) and most open-source projects. GUID (Globally Unique Identifier) is Microsoft's term used in Windows, .NET, COM/OLE, SQL Server and Active Directory. Both refer to the identical 128-bit identifier in the same 8-4-4-4-12 hex format. Functionally interchangeable: a GUID generated by Windows can be used anywhere a UUID is expected, and vice versa.

Can two UUIDs ever be the same?

Mathematically yes; practically no. UUID v4 has 122 random bits, giving approximately 5.3 × 10³⁶ possible values. By the birthday paradox you'd need to generate roughly 2.71 × 10¹⁸ UUIDs to have a 50% chance of any collision, at 1 billion UUIDs per second continuously, that's about 86 years. For application-scale generation rates the practical risk is zero. The most common cause of "duplicate UUIDs" in real systems is a buggy generator using Math.random() instead of a CSPRNG, not the underlying math.

Are these UUIDs cryptographically secure?

Yes. The generator uses the browser's crypto.randomUUID() (where available) or crypto.getRandomValues() as a fallback. Both draw entropy from the operating system's CSPRNG, Linux getrandom(), Windows BCryptGenRandom, macOS SecRandomCopyBytes: the same source TLS uses for session keys. The output is suitable for security-sensitive use cases like session tokens or idempotency keys.

Should I use UUID v4 or v7 for my database primary key?

v7 is the modern recommendation if your database supports it. v4 (random) inserts at random positions in B-tree indexes, fragments the index, and trashes the page cache. v7 (timestamp + random, RFC 9562 May 2024) inserts at the rightmost edge of the index because IDs sort by creation time, same write performance as auto-increment integers, with the distribution and uniqueness of UUIDs. Postgres 18+ has uuidv7() built in. The trade-off: v7 leaks the creation time of each row, which can be a privacy concern in some applications. For most use cases the performance win outweighs the timestamp leak.

What are ULID, KSUID and nanoid?

Alternative ID formats. ULID (Alex Knol, ~2016): 128 bits like UUID but encoded as 26 Crockford-Base32 characters; sorts lexicographically by timestamp. KSUID (Segment, 2017): 27 characters, second-precision timestamp + 128 random bits. nanoid (Andrey Sitnik, 2017): tiny library producing URL-safe random IDs of configurable length; default 21 characters give similar collision resistance to UUID v4 in many fewer bytes. Snowflake (Twitter, 2010): 64-bit IDs that fit in a SQL BIGINT, used by Twitter, Discord and Instagram. Use UUID when the receiving system expects UUID format; use the alternatives when you have specific size, sortability, or URL-friendliness requirements.

Are the UUIDs sent anywhere?

No. Every UUID is generated locally in your browser using the Web Crypto API. The generator never makes a network request, verify in DevTools' Network tab while you click Generate, or take the page offline after it loads and confirm the tool still works. Safe for generating session tokens, idempotency keys, or other identifiers where you don't want a third party to have seen the value before you use it.

Related Tools