UUID Generator: v4, v7, v5 and Bulk Lists

Which version should a UUID generator give you?

Every UUID is 128 bits written as 32 hex digits in five groups, 8-4-4-4-12. Two of those digits are bookkeeping: the 13th digit is the version, and the 17th carries the variant (8, 9, a or b for RFC 9562 UUIDs). Everything else is what the version puts there: random bits, a timestamp, a counter or a hash. Picking the version is really picking which of those you want inside your key.

My rule of thumb: v4 unless the ID is a database key that gets inserted a lot, then v7. RFC 9562 itself says implementations should use v7 instead of v1 and v6 where possible. Name-based v5 is the odd one out: it is not about uniqueness over time but about getting the same answer twice, which is exactly what you want when two services must agree on the ID of "https://example.com/item/42" without talking to each other. The v4 vs v7 guide walks through the index side of that decision.

A practical warning about v7: its first 12 hex digits are the creation time in milliseconds, readable by anyone. Paste 017f22e2-79b0-7cc3-98c4-dc0c0c07398f into the Validate & decode tab and you get the exact moment it was made. If an ID is shown to users and the timing is sensitive, give them a v4.

Formats: the same 128 bits, seven spellings

Most "invalid UUID" errors I have chased were not bad IDs at all, just the wrong spelling for the system on the other end. The generator keeps the bits and changes only the text, so the same value can go into each of these:

The separator option (hyphen, none, dot or underscore) applies to the plain, upper-case and braces forms only; a URN with dots would no longer be a valid URN, so the tool locks the separator for it. Input is the other way round: RFC 9562 asks for lowercase output but case-insensitive input, and the decoder accepts all of the forms above except Base64. If you need the .NET byte order or the habits of SQL Server, read UUID vs GUID.

Bulk lists for fixtures and seed files

The Bulk tab makes 1 to 10,000 IDs at once and exports them as plain text, CSV with a uuid header, a JSON array, or a ready INSERT INTO items (id) VALUES … statement (rename the table and column to yours). Two details matter more than the count:

• v7 lists are strictly ascending. Ten thousand IDs are made within a few milliseconds, so most share a timestamp. Without a counter they would come out in random order inside each millisecond; with it, the list sorts the same as text and as bytes, and the info line confirms "strictly ascending".
• v5 and v3 take names, one per line. Paste a column of domains, URLs or product codes and you get one deterministic ID per line, identical to what Python's uuid5() returns for the same namespace and name.

Can two UUIDs ever be the same?

For random v4 IDs the honest answer is "yes, with a probability you can compute and then stop worrying about". With 122 random bits, the birthday approximation gives:

Worked example: you create one billion v4 IDs, n = 10⁹. Then n² = 10¹⁸, 2 × 2¹²² ≈ 1.063 × 10³⁷, the exponent is about 9.4 × 10⁻²⁰, and p ≈ 9.4 × 10⁻²⁰. At a trillion IDs it is about 9.4 × 10⁻¹⁴. You need roughly 2.7 × 10¹⁸ IDs before the chance of a single duplicate reaches one half.

The real risk is never the math, it is a weak random source: a copied snippet built on Math.random(), a forked process that reuses its seed, or a VM image cloned with the same state. This generator takes every random bit from crypto.getRandomValues(), the browser's cryptographic generator. For v7, two independent generators only clash if they pick the same millisecond and then match on roughly 73 random bits (the counter is seeded with 41 random bits and 32 more bits stay random). Still, put a unique constraint on the column: it costs nothing and turns a theoretical problem into a loud error.

Validate and decode: what an ID tells you

Paste one UUID into the Validate & decode tab and you get its canonical form, version, variant, the embedded time for v1, v6 and v7 (UTC and your local time), the clock sequence and node of v1/v6, plus the BINARY(16) hex and Base64 spellings. The node check tells you whether a v1 ID carries a random node (multicast bit set, as RFC 9562 recommends) or something that looks like a real network card address, which is a privacy leak worth knowing about.

Paste a whole column instead and it becomes a list check: how many lines are valid, which are not and why ("found 31 hex digits", "hyphens must split the digits 8-4-4-4-12"), how many are duplicates, whether the list is in ascending order, and which versions it contains. That is the quickest way I know to audit an import file before it hits a unique index.

It is also strict where old validators were sloppy. A UUID whose version digit is 0 is not the Nil UUID unless all 32 digits are zero; an ID with the Microsoft legacy variant (17th digit c or d) is well-formed but its version digit means nothing, and the result says so instead of inventing a version.

Storing UUIDs without regret

1. Use the native type. PostgreSQL uuid and SQL Server uniqueidentifier store 16 bytes. A 36-character text column is more than twice that in the table and in every index that includes it. In MySQL, use BINARY(16); the 0x format gives you the literal.
2. Pick v7 for clustered or heavily inserted keys. New v7 values land at the end of the index instead of on random pages.
3. Keep one canonical spelling in your API. Lowercase with hyphens. Compare case-insensitively if you accept input from other systems.
4. Never treat a UUID as a secret. RFC 9562 says not to assume UUIDs are hard to guess. Password-reset links and API keys need a dedicated random token.
5. Do not ship v1 with a real MAC address. It identifies the machine and the moment. This tool always uses a random node.

For the one-liners that create UUIDs in PostgreSQL, JavaScript, Python, Java and C#, see how to generate a UUID in code.

Where the bits come from, and how I test them

Everything happens in your browser; the page sends nothing anywhere. Random bits come from crypto.getRandomValues(). Version 7 follows RFC 9562 §6.2 method 1 with a 42-bit counter (the same scheme as Python's uuid7()): a fresh random seed every new millisecond, plus one for every further ID in that millisecond, and if the clock steps backwards the last timestamp is reused so the order never breaks. Versions 1 and 6 count 100-nanosecond ticks since the start of the Gregorian calendar, add one tick per ID inside the same millisecond, and use a random node with the multicast bit set. Versions 5 and 3 hash the 16 namespace bytes followed by the UTF-8 name with SHA-1 or MD5 and then set the version and variant bits, exactly as the RFC 9562 text and the Python uuid module do.

The previous script on this site had a real bug worth confessing: its v1 timestamp arithmetic overflowed a signed 32-bit integer, so for about half of every seven minutes it produced IDs starting with a minus sign. Its v7 output also came out unsorted inside a millisecond. Both are fixed, and these are among the control cases the tool is tested against on every change: