UUID Generator (v4, v7, ULID, NanoID)

UUID v4 or UUID v7: which should you use?

A UUID is a 128-bit identifier written as 32 hexadecimal digits in five groups, such as 3f2c8a1e-5b7d-4e9f-a0c1-2d3e4f5a6b7c. Six of those bits are fixed: four give the version (the first digit of the third group) and two give the variant (the first digit of the fourth group is 8, 9, a or b for standard UUIDs).

Version 4 fills the other 122 bits with random data. It is the default almost everywhere, reveals nothing about when or where it was made, and the chance of two colliding is negligible: you would need to generate about a billion per second for 85 years to reach even odds of a single duplicate.

Version 7, standardised in RFC 9562 in 2024, puts a 48-bit Unix timestamp in milliseconds at the front and fills the rest with random bits. New v7 IDs therefore sort in creation order, which keeps database B-tree indexes compact: inserts land at the end of the index instead of on random pages, and that is the main reason Postgres, MySQL and SQL Server users are switching primary keys from v4 to v7. The trade-off is that anyone holding the ID can read when it was created. This generator keeps v7 IDs strictly increasing even within the same millisecond by using the 12-bit counter the RFC describes.

ULID and NanoID

Use ULID when you want time ordering in a shorter, case-insensitive string; use NanoID for public-facing IDs such as short links or invite codes, where length matters and time ordering does not.

ULID

26 characters of Crockford base32, such as 01JAZ1S83VV6F35M4HSN97TA7X: a 48-bit millisecond timestamp followed by 80 random bits. It sorts lexically by time, avoids the look-alike letters I, L, O and U, and fits the same 128 bits as a UUID, so it can be stored in a uuid column. Monotonic mode increments the random part for IDs made in the same millisecond.

NanoID

A compact random string, 21 characters of A–Z, a–z, 0–9, _ and - by default, which gives about 126 bits of randomness: as collision-resistant as UUID v4 in fewer characters, and safe in URLs and file names without encoding.

Custom alphabets

NanoID can use digits only, lowercase only, alphanumerics, an alphabet without look-alike characters, or any set you type. The tool shows the resulting bits of randomness so you can pick a length that stays safe.

GUID, braces and other formats

A GUID is Microsoft's name for the same thing as a UUID. .NET, the Windows registry and COM often print it in UPPERCASE inside braces, like {3F2C8A1E-5B7D-4E9F-A0C1-2D3E4F5A6B7C}, which is what the braces option produces. Some systems want the 32 digits without hyphens; others store them in a binary(16) column. All of these are the same 128 bits.

The quoted formats add the commas for you, so a thousand IDs can go straight into WHERE id IN (…) or a JSON array. For realistic rows rather than bare IDs, the Mock Data Generator builds whole tables with UUID columns.

Reading an existing UUID

The inspector accepts a UUID with or without hyphens, braces, quotes or a urn:uuid: prefix, and a ULID in either case. It tells you whether the value is well-formed, which version and variant it declares, and, for time-based versions 1, 6 and 7 and for ULIDs, the embedded creation time as an ISO 8601 date in your own time zone and in UTC.

Versions 3 and 5 are hashes of a namespace and a name (MD5 and SHA-1), so the same input always gives the same UUID and there is no time to read. Version 8 is reserved for custom layouts. The nil UUID (all zeros) and max UUID (all ones) are special values defined by the RFC.