UUID Generator

What a UUID is

A UUID — Universally Unique Identifier — is a 128-bit number that, in practice, you can generate in isolation and trust will not collide with one generated by anyone else, anywhere. The trick is the math: 128 bits is roughly 3.4 × 10³⁸ possible values, so even generating a billion random UUIDs per second for a hundred years gives you something like a one-in-a-trillion chance of seeing a duplicate.

The canonical text form is 32 hex digits split into five groups separated by hyphens: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx. The M position encodes the version (which generation algorithm was used) and the N position encodes the variant.

Versions you'll actually see

Version 4 (random)

The default. 122 bits of randomness from a cryptographic RNG, with 6 bits reserved for version and variant. Easy to generate, no coordination needed, and good enough for almost every application that needs an identifier. This tool generates v4 by default.

Version 7 (timestamp + random)

The newest one (RFC 9562, 2024) and the one you should reach for in databases. The first 48 bits are a Unix timestamp in milliseconds, followed by 74 bits of randomness. Because the timestamp is at the start, sorting v7 UUIDs lexically also sorts them by creation time — which makes them dramatically friendlier as database primary keys than v4. Random v4 IDs scatter inserts across a B-tree index and trash write performance on large tables; v7 inserts cluster at the tail, which is what you want.

Version 1 (timestamp + MAC address)

The original time-based UUID. Combines a 60-bit timestamp with the generating machine's MAC address. Useful in narrow circumstances but mostly avoided now: leaking the MAC is a privacy issue, and v7 gets you the same sortability without the leak.

UUID vs. auto-increment integers

The two competing styles for primary keys. Integers are smaller (8 bytes vs. 16), faster to compare, and easy to read aloud. UUIDs are 16 bytes, opaque, and a pain to type, but they have a property integers don't: you can mint one client-side, before talking to the server, and have it survive offline edits, multi-master replication, and merging data across services. If you've ever needed two systems to agree on an ID without a central allocator, that's the case for UUIDs.

Common pitfalls

• Storing as a string in a database. A UUID stored as CHAR(36) takes more than twice the space of the binary form (16 bytes) and indexes more slowly. Most databases now have a native UUID type — use it.
• Using Math.random(). Browser Math.random() is not cryptographically random and shouldn't be used to generate UUIDs you'll rely on for uniqueness or unguessability. This tool uses crypto.getRandomValues().
• Treating a UUID as a security token. v4 UUIDs are random enough to use as session IDs in some contexts, but think about it explicitly — 122 bits of entropy is fine, predictable v1 timestamps are not.

Just give me one

Hit Generate. The output is ready to paste into a config file, a test fixture, a database row, or wherever you need a unique value to exist.