UUID Generator

A UUID is 128 bits written as 32 hex digits in five hyphenated groups. What people usually need to know is not the encoding but which of those 128 bits are random, because that decides whether the value is merely unique or also ordered — and whether it is safe as a primary key.

Version 4: pure randomness, no order

Version 4 fixes six bits (four for the version number, two for the variant) and fills the remaining 122 with randomness. That gives 2^122 possible values, about 5.3 × 10^36: generating a billion UUIDs a second for a century collides with probability around 10^-18. The property you give up is order. Two v4 values created a millisecond apart look nothing like each other, and sorting them tells you nothing about when they were made.

If any part of your system assumes "sort the ids" means "sort by creation time", v4 will silently break it. That assumption hides in pagination cursors, "latest N" queries, log correlation and merge logic, and it usually surfaces months later when the ordering happens to matter.

Version 7: a timestamp in front of the randomness

Version 7 was standardised in RFC 9562 to fix exactly that. The first 48 bits are a Unix millisecond timestamp, then four version bits, then 12 random bits, two variant bits and 62 more random bits. The readable consequence is that a v7 value begins with the same digits as the instant it was created, so sort(uuids) is also sort by creation time, and a value generated now is always greater than one generated yesterday. This is the same idea ULID uses; v7 simply carries it inside the standard UUID layout, so existing uuid columns and types accept it without a migration.

Why sortability matters to a database

In a B-tree or clustered index, rows are stored in key order. A random key inserts into a random leaf page, which means the index must touch a different page for every insert, keep more pages in the buffer cache, and split pages in a scattered pattern. A time-ordered key appends to the rightmost page that is already in memory, so inserts are cheap and the index stays dense. On a write-heavy table the difference in throughput and index bloat is measurable, which is why the v4-versus-v7 question is really a storage-engine question.

Two caveats are worth stating plainly. First, v7 leaks its creation time to anyone who can read the value, so do not use it where the timestamp itself is sensitive — a v4 value reveals nothing. Second, v7 is only approximately ordered: values generated in the same millisecond on different machines can interleave, and a machine whose clock moves backwards can produce a value that sorts before an older one. If you need strict global monotonicity, add a counter or a sequence; v7 gives you locality, not a lease on correctness.

Where the randomness comes from

Both versions draw from crypto.getRandomValues, the same platform CSPRNG used for encryption keys. Math.random is explicitly not used: it is a fast non-cryptographic generator whose internal state can be recovered from its outputs, so two processes seeded alike can collide and an observer can predict future values. For an identifier that is meant to be unguessable — a session token, a password-reset link — that difference is the whole point.

You can verify the local claim in a few seconds. Open the developer tools, clear the network panel, and press Generate. No request is made, because the entropy and the formatting both happen in the page. Then disconnect from the network and generate again: the values keep coming.

Are these UUIDs actually random, or generated with Math.random?

They come from crypto.getRandomValues, the browser and Node platform CSPRNG, never from Math.random. That matters because Math.random is not cryptographic: its internal state can be reconstructed from a handful of outputs, so two systems that seed it the same way can collide, and an attacker who observes a few values can predict the rest. Version 4 needs 122 unpredictable bits, and only the platform CSPRNG supplies them.

What is the difference between UUID v4 and v7?

Version 4 is 122 random bits and nothing else, so its values are unique but unordered — two v4 values generated a millisecond apart are indistinguishable. Version 7 puts a 48-bit millisecond timestamp first, then version and variant bits, then 74 random bits. The timestamp prefix means v7 values sort lexicographically in creation order, which is what makes them useful as database keys.

Should I switch my primary key from v4 to v7?

Consider it if you store UUIDs in a clustered B-tree index — Postgres, MySQL InnoDB, SQL Server. Random keys scatter inserts across every page of the index, causing page splits and write amplification; time-ordered keys append to the right-hand edge instead. The trade-offs are that a v7 exposes its creation time (roughly) and that two servers generating in the same millisecond can still interleave, so strict global ordering needs a coordination scheme rather than v7 alone.

Can I generate more than a thousand at once?

No. The ceiling is 1,000 values per batch, and a larger request is rejected with an error rather than silently truncated. A thousand hyphenated UUIDs is about 36 KB of text; rendering far more than that in a page makes the tab stall, and if you need millions you want a script calling the same crypto API, not a browser tab.

Are the generated values sent anywhere or stored?

No. The values are produced by the Web Crypto API in the page and never leave it. There is no counter on a server, so nothing is logged and no request is made when you press Generate. You can confirm this with the network panel or by going offline.