UUID Generator & Inspector

Generate UUIDs in every common version – and break any UUID down bit by bit: which version, which variant, which point in time is buried inside, and how much of it is randomness at all. Your browser does all the work; nothing leaves this device.

Which UUID version should I use?

The short answer for almost every case: version 7 if the IDs end up in a database, version 4 otherwise. Everything else is a special case with a specific reason behind it.

Why v7 is faster than v4 in a database

The difference has nothing to do with cryptography and everything to do with how indexes are built. A B-tree, which PostgreSQL, MySQL and SQL Server all use for primary keys, keeps its entries sorted. Every new value has to go where it belongs – and with a v4 UUID that is a different, random place in the tree every single time.

Under a stream of inserts that means constantly touching pages that are not currently in memory, and splitting pages in the middle. The index becomes sparse and grows faster than it needs to. A v7 UUID, by contrast, starts with time. New values are almost always larger than everything before them and therefore land at the right-hand edge of the tree – on the same few pages that are in cache anyway. This is exactly why uuid_generate_v4() performs so poorly in write benchmarks and why MySQL users spent years building their own “ordered UUID” functions. Since RFC 9562 (May 2024), v7 is the official way to get there.

The price: a v7 UUID reveals when it was created, down to the millisecond. Where that matters – for IDs that are publicly visible and should not disclose timing – v4 remains the better choice.

How a UUID is put together

A UUID is a 128-bit value written as 32 hexadecimal digits in five groups:8-4-4-4-12. Six of those bits are fixed, and they sit in the same place in every version: four bits for the version (the first character of the third group – a UUID with a 7 there is a v7) and two bits for the variant (the highest bits of the first character of the fourth group, which is why that position is almost always 8, 9, a or b in practice).

The variant answers the question of which rules apply to the rest at all. The value10 means RFC 9562 (formerly RFC 4122) and therefore everything in use today.110 marks the old Microsoft GUIDs, 0 the long-forgotten Apollo NCS format. The inspector above highlights exactly these six bits – at a glance you can tell whether a string really is a well-formed UUID or merely looks like one.

The remaining 122 bits belong to the version: in v4 they are pure randomness, in v7 the first 48 of them hold the milliseconds since 1970, and in v1 and v6 a timestamp in 100-nanosecond steps since 15 October 1582 – the day of the Gregorian calendar reform.

How unique is a UUID really?

A v4 UUID has 122 random bits, which is roughly 5.3 × 10³⁶ possible values. What matters, though, is not that number but the birthday problem: the chance that some two UUIDs match grows faster than the count of generated values suggests. The well-known figure: you would have to generate a billion UUIDs every second for about 85 years to have a 50 % chance of hitting a single duplicate.

All of that rests on the quality of the randomness. This tool usescrypto.getRandomValues(), the browser's cryptographically secure random number generator. Where a plain Math.random() or a generator seeded with a fixed value is involved instead, those numbers no longer hold – collisions in the wild almost always trace back to that rather than to mathematical bad luck.

Name-based UUIDs: v3 and v5

v3 and v5 are the only versions without randomness. They hash a namespace (itself a UUID) together with a name and cut the first 16 bytes out of the digest. The same inputs therefore produce the same UUID anywhere, at any time – on another machine, in another year, in another programming language.

That is useful whenever an ID should be derived from something that already exists: a domain, a URL, an ISBN. No table is needed to remember which UUID belongs to which name – the mapping can be recomputed at will. RFC 9562 defines four standard namespaces for this (DNS, URL, OID, X.500); for your own data you generate a v4 UUID once and keep using it as the namespace.

Two pitfalls: first, a name-based UUID is not a one-way street in the security sense. Anyone who knows the namespace and guesses the name can recompute the UUID, so it is useless as a secret. Second, the UUID changes as soon as the name changes, even if only in capitalisation: what gets hashed is the bytes, not the meaning.

Frequently asked questions

What is the difference between a UUID and a GUID?
None that changes the number. GUID (“globally unique identifier”) is Microsoft's name for the same 128-bit construct. Only the writing habits differ: in the Microsoft world GUIDs often appear in curly braces and in uppercase. The generator above produces both notations on request.

Does capitalisation matter?
Not for comparison – A1B2 and a1b2 are the same number. RFC 9562 requires UUIDs to be output in lowercase and read in either case. If you store UUIDs as text in a database, still settle on one form: an = comparison will not find them again otherwise.

Can I use a UUID as a password replacement or an invitation token?
Only if it is a v4 from a cryptographically secure generator – 122 bits of randomness are then more than enough. In v1, v6 and v7 a large share of the bits is the timestamp and therefore predictable; v3 and v5 contain no randomness at all. Such UUIDs are guessable and do not belong in a password-reset URL.

Does a v1 UUID really reveal the MAC address?
The classic implementation does write the network card's MAC address into the last 48 bits, yes. That is precisely how the Melissa virus was once traced back to its author through the GUIDs in Word documents. For this field the inspector above shows whether the multicast bit is set: if it is, the node ID was random; if it is not, there is probably a real network address in there. The generator here always sets it – a browser has no access to the MAC anyway.

Should I store UUIDs as text or as binary?
As binary wherever the database offers it: 16 bytes instead of 36 characters, and the index stays correspondingly smaller. PostgreSQL has a dedicated uuid type, MySQL usesBINARY(16). For logs, config files and APIs the canonical text form with hyphens remains the norm.

Are the generated UUIDs stored anywhere?
No. Generating and inspecting happen entirely in your browser; there is no server that could receive anything. The only thing remembered is your choice of version, count and notation – in your browser's local storage, so the settings are still right on your next visit.