UUID generator

Why v4 is the default

A version 4 UUID is 122 random bits with six bits spent on version and variant markers. That is the whole design. It works because 2¹²² is an absurd number: you would need to generate roughly a billion UUIDs per second for about 85 years before the chance of a single collision reached even 50%. For any application you are actually building, treating v4 as unique is safe.

The important detail is where the randomness comes from. This page uses crypto.getRandomValues, the browser's cryptographically secure generator — the same source used for TLS session keys. Plenty of code in the wild builds UUIDs out of Math.random(), which is a fast non-cryptographic generator with far less entropy and predictable internal state. If the identifier is ever used as a capability — a password-reset link, an unguessable share URL — that difference is the whole security model.

When v7 is the better choice

Version 7, standardised in RFC 9562 in 2024, replaces the top 48 bits with a millisecond Unix timestamp and fills the rest with randomness. The result still looks like a UUID and is still effectively unique, but it sorts in creation order.

That matters for databases. A B-tree index on a random v4 primary key scatters every insert across the whole index, dirtying pages everywhere and destroying write locality — the effect is well documented in both MySQL and PostgreSQL under heavy insert loads. With v7 the new rows land at the right-hand edge of the index, which is what an auto-incrementing integer would have done, without giving away your row count in public URLs. If you are choosing a primary key type for a new table today, v7 is usually the better default. The inspector at the bottom of this page will read the embedded timestamp back out of any v7 you paste into it.

v5 is not random at all

Version 5 takes a namespace UUID and a name, concatenates them and hashes the result with SHA-1, then forces the version and variant bits into place. The same namespace and name always produce the same UUID — on any machine, in any language, forever. That is the point: it lets two systems that have never spoken derive the same identifier for the same thing.

The four predefined namespaces come from the specification: DNS for hostnames, URL for addresses, OID for object identifiers, and X.500 for directory names. You can also supply your own namespace UUID, which is what most projects do — generate one v4, write it into your codebase as a constant, and derive everything else from it. Note that v5 is a name-to-identifier mapping, not a security mechanism: anyone who knows the namespace can compute the same value, and SHA-1 is not appropriate for anything requiring collision resistance.

Formatting, and the ones that are not identifiers

The canonical form is 36 characters: 32 lowercase hex digits in a 8-4-4-4-12 grouping. Microsoft's ecosystem writes them in braces and often in uppercase, which is why the GUID you copy out of the Windows registry looks different from the one in your Postgres row — they are the same 16 bytes. The hyphens carry no information and stripping them is safe if your storage is tighter than your patience. All four variations are on the format row above.

The nil UUID (all zeros) and the max UUID (all ones) are reserved sentinels, not identifiers. They are useful as an explicit "no value" that still type-checks as a UUID, and both are included for when you need one to hand.

Generated here, not fetched

There is a whole category of UUID sites that call an API and hand you back whatever the server produced. That is a strange trust relationship for a value whose only property is that nobody else should be able to predict it. Everything on this page comes from your own machine's random number generator, and the page makes no network requests after it loads. If you need hashes rather than identifiers, the hash generator works the same way.