UUID Generator
Generate cryptographically random UUID v4, time-ordered v7 and Nano IDs.
Guide & FAQWhich UUID version should you use? · Why v7 matters for databases · What UUIDv7 actually is · The tradeoff nobody mentions · Collision probability · Nano ID and short IDs · Frequently asked questions
Which UUID version should you use?
| Version | Based on | Use it when |
|---|---|---|
| v4 | 122 random bits | You just need a unique identifier and do not care about ordering. The safe default. |
| v7 | 48-bit millisecond timestamp + randomness | The ID becomes a database primary key. Values sort chronologically, which keeps B-tree indexes compact. |
| v1 | Timestamp + MAC address | Legacy systems only — it can leak the generating machine's network address. |
| v5 | SHA-1 of a name inside a namespace | You need the same input to deterministically produce the same UUID. |
Why v7 matters for databases
Random v4 values are inserted at scattered positions in an index, which fragments pages and hurts write throughput on large tables. UUID v7 puts the timestamp in the most significant bits, so new rows append at the right edge of the index — the same locality an auto-increment integer gives you, without a central sequence.
What UUIDv7 actually is
UUIDv7 was standardised in RFC 9562 in May 2024, which replaced the long-serving RFC 4122. Its layout is what makes it different from v4:
| Bits | Contents |
|---|---|
| 48 | Unix timestamp in milliseconds, big-endian, in the most significant position |
| 4 | Version — always 7, the first character of the third group |
| 2 | Variant — always 8, 9, a or b, the first character of the fourth group |
| 74 | Random, from a cryptographic source |
Because the timestamp occupies the leading bits, v7 values are time-sortable as plain strings. Two identifiers generated a millisecond apart compare in the order they were created, with no parsing and no separate column — which is the property the database benefit above is built on. Sorting a list of v7 strings alphabetically sorts it chronologically.
The tradeoff nobody mentions
A v7 identifier tells you when it was created. The first twelve hex characters are a millisecond timestamp, readable by anyone holding the value:
01a063b0-47ce-7bc9-89a6-aeebe0a9a896
^^^^^^^^^^^^ = 0x01a063b047ce ms since 1970
That is usually harmless and occasionally not. A v7 in a public URL discloses when the record was made — when an account signed up, when a document was drafted, when an order was placed. If the identifier is exposed to users and the creation time is not something you would print next to it, use v4, which carries 122 random bits and reveals nothing at all.
The choice is therefore less about which version is newer and more about where the value goes: v7 for primary keys and internal references, where index locality pays for itself; v4 for anything a stranger will see.
Collision probability
A v4 UUID carries 122 random bits, or about 5.3 × 1036 possible values. Generating a billion UUIDs per second for a century leaves the chance of a single collision far below one in a billion — assuming a proper cryptographic random source, which is exactly what crypto.getRandomValues() provides.
Nano ID and short IDs
Nano ID packs similar collision resistance into 21 URL-friendly characters instead of 36, which is why it is popular for public-facing slugs. The 8-character short ID here is for throwaway keys and demo data only — with roughly 2.8 × 1014 combinations, collisions become likely once you pass a few million values.
Frequently asked questions
Are these UUIDs really random?
Yes. They come from crypto.getRandomValues(), the browser’s cryptographically secure random number generator — the same source used for key material — not from Math.random().
Could the server see the values I generate?
No. Generation happens entirely in your browser after the page loads, so the values are never transmitted and the tool works offline.
Is a UUID safe to expose in a URL?
A v4 UUID reveals nothing about its contents, so it is fine as an opaque identifier. It is not a substitute for authorisation, though — anyone who obtains the URL can use it.
How should I store a UUID in a database?
Use a native UUID column where one exists (PostgreSQL uuid, SQL Server uniqueidentifier) or a 16-byte binary column such as MySQL BINARY(16). Storing it as a 36-character string more than doubles the space and slows comparisons.
What is the difference between UUID v7 and ULID?
Both prefix random bits with a millisecond timestamp so values sort by creation time. ULID uses a 26-character Crockford base32 encoding; UUID v7 keeps the standard 36-character UUID format, so existing UUID columns and libraries accept it unchanged.