UUID / GUID generator

UUID or GUID?

The same 128-bit value under two names. "GUID" is Microsoft's term, and Windows tooling — the registry, COM, .NET, SQL Server — conventionally prints it in upper case wrapped in braces: {6BA7B810-9DAD-11D1-80B4-00C04FD430C8}. Everyone else writes the same bytes as lower-case hex with hyphens. That is a presentation difference, not a different kind of identifier, which is why the format switches above change how the value is displayed and never what it is.

The specification is RFC 9562, published in May 2024 to replace RFC 4122. It kept the old versions intact and added v6, v7 and v8, so nothing you already have becomes invalid.

Which version do you want?

Why v7 is the one worth knowing about

A v4 UUID is uniformly random, which means consecutive inserts land in unrelated places in a database index. On a B-tree that turns an append into a scattered write across the whole index: pages split, the working set stops fitting in cache, and insert throughput falls away as the table grows. It is the standard argument against UUID primary keys, and it is a fair one.

v7 puts a millisecond Unix timestamp in the leading 48 bits, so ids generated later are always larger. Inserts go to the end of the index the way an auto-increment integer does, while the trailing random bits keep them unguessable and safe to generate on several machines at once. Sorting a list of v7 UUIDs as plain text sorts them by creation time, which is often reason enough on its own.

The cost is honest and worth stating: a v7 UUID tells anyone who sees it when it was created, to the millisecond. For an order id that is usually harmless. For a password-reset token or an invitation link it may not be, and there v4 is the better choice.

One detail this generator handles that many do not: when you ask for a hundred at once, they all land in the same millisecond or two. The 12 bits after the version nibble are used as a counter rather than more randomness — a method the RFC specifically allows — so the batch is strictly increasing rather than shuffled within each millisecond.

v5, and the deterministic case

v5 is not random at all. It is the SHA-1 of a namespace UUID followed by a name, with the version and variant bits stamped in. Feed it the same namespace and the same name and you get the same UUID on any machine, in any language, forever — which is exactly what you want when two systems have to agree on an id for something without talking to each other. Turning a URL into a stable content id is the classic use.

The four namespaces in the dropdown are the ones defined by the spec (DNS, URL, OID, X.500). If your ids are not any of those things, mint one v4 UUID, keep it as your project's own namespace, and paste it into the custom field. That is the intended pattern.

Two caveats. The mapping is not a secret: anyone can compute the same UUID from the same name, so a v5 id is not a capability. And SHA-1 being broken for collision resistance does not matter here — there is no signature to forge — but it is why v5 exists rather than being the default. v3 is the same idea with MD5; it is not offered here because browsers' Web Crypto does not implement MD5, and there is no reason to ship one to provide a strictly worse version of a thing you can already do.

Are they actually unique?

Not guaranteed — just overwhelmingly likely, which for practical purposes is the same thing. A v4 UUID carries 122 random bits. To reach a coin-flip chance of a single collision you would need to generate roughly 2.7 × 10¹⁸ of them: a billion per second, continuously, for about 85 years.

The real risk is never the birthday bound, it is a bad random source. A generator seeded from Math.random, or one running on a device with a broken entropy pool, can repeat itself quickly. This page draws every random bit fromcrypto.getRandomValues, the browser's interface to the operating system's CSPRNG, and refuses to produce anything at all if that is unavailable.

Storing them

A UUID is sixteen bytes. Written out it is 36 characters, 38 with braces, 32 without hyphens. Storing it as CHAR(36) costs more than twice the space and makes every index comparison a string comparison; most databases have a native type (uuid in PostgreSQL, BINARY(16) in MySQL,uniqueidentifier in SQL Server) that stores the bytes. If you useBINARY(16) in MySQL, remember that its UUID_TO_BIN(x, 1) swaps the time fields of a v1 UUID to make it sortable — with v7 you do not need that trick at all.

Questions

Can I use a UUID as a security token?

A v4 UUID from a cryptographic random source has 122 bits of entropy, which is more than enough to be unguessable. But v1 and v7 are largely predictable — most of their bits are a timestamp — and plenty of libraries produce "v4" UUIDs from a non-cryptographic PRNG. If the value has to be unguessable, generate a token deliberately rather than reaching for a UUID and hoping.

Why does the v1 output not contain my MAC address?

Because a browser cannot read it, and should not be able to. The spec covers this case: when the hardware address is unavailable, use a random node id with the multicast bit set, which is what happens here. The original v1 design leaking the machine's MAC address into every identifier it produced is precisely why v1 fell out of favour.

Do you log the UUIDs, or generate them server-side?

Neither. The generator is JavaScript that has already been downloaded by the time you see a result — disconnect from the network and press "Generate again" and it keeps working. Nothing is stored either, so reloading loses whatever was on screen.

Can I get more than a hundred at a time?

Not from the buttons. If you need thousands, generate them where you need them: every language has a UUID library, and modern browsers and runtimes havecrypto.randomUUID() built in, which produces a v4 in one call.

Is upper case allowed?

Yes to read, discouraged to write. RFC 9562 says generators should output lower case and that parsers must accept either — so upper case here is for pasting into tools that expect the Windows style, not a form you should be storing.