UUID & GUID Generator

UUID stands for universally unique identifier. It is a 128-bit number, written as 32 hexadecimal digits grouped 8-4-4-4-12, designed so that anyone can generate one at any time without coordinating with anybody else and still be confident it has never been generated before.

GUID means globally unique identifier and is Microsoft's term for a UUID. The bits are identical and the two are interchangeable. The only real difference is convention: Microsoft tooling tends to write a GUID in uppercase and wrap it in braces, as in {019A0C2E-7D51-7B8E-9F42-6AC3D0B81E77}. Switch on Uppercase and Braces above and this page produces exactly that form.

Turn the Hyphens toggle off. The hyphens carry no information at all — they are a readability convention in the canonical form — so removing them leaves the same 32 hexadecimal digits and the same 128 bits. The 32-character form is common in URLs, filenames and compact database columns, and the decoder on this page reads it back happily.

A v4 is 122 random bits and nothing else, so two v4s created a second apart have no relationship. A v7 spends the first 48 bits on a Unix millisecond timestamp and fills the remaining 74 with randomness, so v7 values sort by creation time as plain strings. That matters for database primary keys: random keys scatter inserts across a B-tree index, while time-ordered keys append. Both are 128 bits and both are effectively unique.

On this page, yes, for v6, v7 and ULID. It is worth asking, because a naive implementation fails here: a timestamp only advances every millisecond, so a batch of a thousand generated in a single millisecond shares one timestamp and is then ordered only by its random bits — which is to say, not ordered at all. RFC 9562 §6.2 addresses this directly and asks implementations to add a counter. This page uses the RFC's Monotonic Random method, where the bits after the timestamp are a randomly seeded counter advanced by a random amount for each ID in the tick.

Use v4 for a general-purpose unique value. Use v7 for anything that becomes a database primary key or a sort key. Use v6 instead of v7 when a system is already built on v1 and you need sortable keys without changing the field layout. Use v5 when the identifier has to be reproducible from a name. v1 is worth generating only for compatibility with something that already expects it, and v3 only where MD5 is already the agreed hash — v5 is the same idea with SHA-1.

Version 6 arrived with RFC 9562 in 2024 and is a version 1 with its timestamp rearranged. A v1 stores the least significant part of the timestamp first, which is why v1 values do not sort; a v6 stores the most significant part first, which is why they do. Everything else — the clock sequence, the node field, the field widths — is unchanged, so v6 drops into a system already storing v1 UUIDs. Most generators predate the RFC and simply never added it. This one generates and decodes it.

For a v4 the answer is effectively no, and the figure is derivable rather than folklore. A v4 carries 122 random bits, and the birthday bound puts even odds of a single collision at about 1.1774 × the square root of 2 to the 122nd — roughly 2.7 quintillion UUIDs. Generating a billion every second, you would reach that after about 86 years. The worked figures appear under the results for whichever scheme you pick, including shorter NanoIDs, where the number drops sharply.

The randomness comes from the Web Crypto API, which is a cryptographically secure source, not Math.random. That said, unique is not the same as unguessable, and it is the wrong question for some UUID types. A v1 or v6 exposes the moment it was created and a node value. A v7 exposes its creation millisecond by design. A v3 or v5 is a hash of inputs someone may be able to guess. If a value has to be unpredictable — a session token, a password-reset link — use v4, or a long NanoID, and never a time-based version.

Not from this page. A v1's node field was originally the machine's MAC address, which is exactly why v1 fell out of favour. RFC 9562 §6.10 allows a random node instead, and requires the least significant bit of its first byte to be set — the multicast bit, which a real network card never has — so a randomised node can never be mistaken for a real one. This page draws a random node once per visit and uses it for every v1 and v6 you generate, which is what a single machine would do.

No. RFC 9562, published in May 2024, obsoletes RFC 4122. It keeps versions 1 through 5 unchanged, adds versions 6, 7 and 8, defines the Max UUID alongside the existing Nil UUID, and gives the guidance on batch monotonicity that this page implements. Several well-known generators still describe themselves as RFC 4122 tools, which is a useful way to tell whether one has been updated since 2024.

The Nil UUID is all 128 bits zero and means "no identifier" — it is the value to store when a column needs a UUID and there genuinely is not one. The Max UUID, all 128 bits one, was added by RFC 9562 as the opposite sentinel: it sorts above every other UUID, which makes it useful as an exclusive upper bound in a range query. Neither is generated; both are constants.

A ULID is 26 characters of Crockford base32 holding a 48-bit millisecond timestamp and 80 random bits. It sorts by time like a v7 and is ten characters shorter than a UUID, at the cost of not being a UUID — anything expecting a uuid column type will reject it. A NanoID is a plain random token from a 64-symbol URL-safe alphabet, with the length up to you; the default 21 characters carry 126 bits, slightly more than a v4. Pick ULID when you want sortable and compact, NanoID when you want short and public, and a UUID when something downstream expects the standard format.

Because it cannot, and neither can anything else. A UUID carries a version nibble and variant bits, and a ULID has a length and an alphabet that pin it down — those are structures a decoder can read. A NanoID has none: it is just characters from a 64-symbol alphabet, so a NanoID, a session token and an ordinary English word are indistinguishable by inspection. The decoder therefore reports the length and the maximum randomness that many characters could hold, and stops short of naming a format. Only the system that issued the token can validate it.