UUID Generator
Generate one or hundreds of random UUIDs (v4).
100% in your browser — nothing uploadedGenerate random UUID v4 identifiers
Anatomy of a UUID v4
Example (the highlighted digits are fixed):
3f2b9c1e-7a4d-4f8b-9c2a-5e6d7f8a9b0c
About this UUID generator
A UUID (universally unique identifier) is a 128-bit value written as 32 hexadecimal digits in five hyphen-separated groups — 8-4-4-4-12, as in fb438932-ab5f-4088-88ad-0c037f96ac0e. It is used for database keys, request and trace IDs, filenames and idempotency keys: anywhere you need an identifier you can mint locally, without asking a central authority, and still be confident nobody else minted the same one. Version 4 UUIDs, the kind this page generates, are built almost entirely from random data.
The generator calls crypto.randomUUID(), your browser’s cryptographically secure source, which browsers expose only in secure contexts (HTTPS). On older browsers the page falls back to crypto.getRandomValues() and sets the version and variant bits by hand, producing an identical result. Generate up to 1,000 at a time, optionally uppercase or without hyphens, and copy the whole list in one click. Nothing is requested from a server, so you can load the page, disconnect, and keep generating.
Of the 128 bits, six are not random: four encode the version and two encode the variant. That leaves 122 random bits in a v4 UUID, and you can see the fixed bits in the string — the 13th hex digit is always 4, and the 17th is always 8, 9, a or b. Everything else is entropy. RFC 9562 allows the text form to be uppercase, lowercase or mixed and treats them as the same value, so the uppercase toggle above is purely cosmetic; crypto.randomUUID() emits lowercase, which is what most systems store.
Collision risk is worth reasoning about rather than hand-waving. For n identifiers drawn from N = 2^122 possibilities, the expected number of collisions is about n² / (2N). Reaching a one-in-a-billion chance of a single collision takes on the order of 10^14 UUIDs — a hundred trillion of them. In practice the arithmetic is never the problem; the randomness source is. UUIDs generated from Math.random(), from a virtual machine cloned with its entropy pool intact, or from an embedded device that boots before it has gathered entropy do repeat. If uniqueness genuinely matters, keep the unique constraint on the column.
Version 4 is the right default, but not the right answer everywhere. Because the values are random, consecutive inserts land in random places in a B-tree index; RFC 9562 states that UUID versions which are not time ordered have poor database-index locality and that the resulting effect on B-tree structures can be dramatic. UUIDv7 puts a 48-bit millisecond Unix timestamp in the leading bits so new rows cluster at the end of the index. The trade is real, though: a v7 value publicly discloses when it was created, and PostgreSQL’s own documentation says to prefer v4 when that timestamp has security or business-intelligence implications. RFC 9562 gives the same advice for security-sensitive identifiers.
UUID versions compared (RFC 9562) and the v4 bit layout
RFC 9562, published in 2024, replaced RFC 4122 and added versions 6, 7 and 8 to the original set. Version 2 (DCE Security) was defined elsewhere and is out of scope. In everyday work only three of these come up, but knowing what the others hold makes it obvious why.
| Version | What it contains | When to pick it |
|---|---|---|
| v1 | Gregorian timestamp (100 ns units since 1582), clock sequence, node ID | Legacy. RFC 9562 says a MAC address SHOULD NOT be used as the node, because it leaks the machine. |
| v3 | MD5 of a namespace UUID plus a name | Deterministic IDs from a name, only when MD5 compatibility is forced on you. |
| v4 | 122 random bits | The default. Unpredictable, reveals nothing, supported everywhere. |
| v5 | SHA-1 of a namespace UUID plus a name | Deterministic IDs: the same name always yields the same UUID. Preferred over v3. |
| v6 | v1 fields reordered so the timestamp sorts first | Only to improve locality in a system already committed to v1. |
| v7 | 48-bit Unix ms timestamp, then 74 bits of randomness or counter | Database primary keys. Sorts by creation time, good index locality. |
| v8 | Free-form; only the version and variant bits are fixed | Custom or experimental layouts you control end to end. |
xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx
| |
| variant: always 8, 9, a or b
version: always 4
fb438932-ab5f-4088-88ad-0c037f96ac0eThe database argument for v7 is concrete. A v4 primary key is random, so every insert writes to a random leaf of the B-tree: pages split, the set of hot pages is effectively the whole index, and write amplification climbs. A v7 key increases over time, so inserts mostly append. RFC 9562 puts it directly — time-ordered monotonic UUIDs benefit from greater database-index locality, while non-ordered ones have poor locality with effects that can be dramatic. For a table you expect to grow large, this is usually the deciding factor.
What is actually built in has changed recently, so check your versions before reaching for a library:
| Where | v4 | v7 |
|---|---|---|
| PostgreSQL | gen_random_uuid(), built in since 13 | uuidv7(), new in 18, alongside uuid_extract_timestamp() |
| MySQL | Not built in — UUID() returns a v1 | Not built in |
| Python | uuid.uuid4() | uuid.uuid7(), new in 3.14 |
| JavaScript | crypto.randomUUID() | Not built in — needs a library |
Two closing cautions. Storing a UUID as a 36-character string costs more than double the 16 bytes it actually needs, and that cost is repeated in every index and foreign key that references it — most databases have a native uuid or BINARY(16) type, so use it. And RFC 9562 asks you to treat UUIDs as opaquely as possible: if your application code pulls one apart to read the timestamp out of it, you have coupled yourself to a version you may want to change later. If you need the creation time, store a created_at column.
FAQ
Can two UUIDs collide?
With 122 random bits, the chance is so small it’s ignored in practice: you’d need to generate billions per second for centuries to expect one collision.
What’s the difference between v4 and v7?
v4 is fully random. v7 embeds a timestamp so IDs sort by creation time — better for database indexes. v4 remains the most widely supported.
Are these UUIDs safe for production?
Yes — they come from your browser’s cryptographic random source, identical in quality to what a backend library would produce.