UUID Generator

The anatomy of a UUID

A UUID (Universally Unique Identifier), called a GUID on Microsoft platforms, is a 128-bit number written as 32 hexadecimal digits in the familiar 8-4-4-4-12 layout. Its purpose is to let independent systems mint identifiers that will not clash without asking a central authority for the next number, so two services — or two offline phones — can each create IDs and merge them safely later. Two positions in the string carry meaning. Take this real version-4 value; the version digit and the variant digit are highlighted:

The bold 4 — the first digit of the third group — is the version, and it tells you how the id was built. The bold a — the first digit of the fourth group — is the variant; for the standard layout it is always 8, 9, a or b. Every other digit here is random. Nothing in a v4 encodes where or when it was made. Now compare a version-7 value from the RFC 9562 spec:

Same shape, version digit 7, but the leading 48 bits are a Unix-millisecond timestamp. Because the time sits in the high-order bits, sorting v7 strings lexically sorts them by creation time — the single property that makes v7 so useful as a key.

Which version should you use?

The version digit is the whole story. Only two versions are still worth generating fresh today — v4 and v7 — but you will meet the others in existing data, so here is the full family:

v4 is pure randomness: simple, unguessable, unordered. v7, standardised in RFC 9562 in May 2024, prefixes the same randomness with a millisecond timestamp so a batch generated in sequence sorts in creation order. That matters for databases: random v4 keys scatter inserts across a B-tree and fragment it, while v7 keys append near the end, keeping the index compact and writes fast — much like an auto-increment column, but still globally unique and safe to generate offline. The name-based v3/v5 are a different job entirely: they turn a fixed input (say a URL) into the same UUID every time.

Name-based v5 UUIDs: same input, same id

The Namespace tab makes a different kind of UUID. Instead of randomness, a v5 UUID is the SHA-1 hash of a namespace plus a name, so the same two inputs always yield the same id — on any machine, forever. That is exactly what you want when an id must be derived from something you already have (a hostname, a URL, a file path) rather than stored in a lookup table. The construction, per RFC 4122, is precise about byte order:

RFC 4122 blesses four ready-made namespaces — DNS, URL, OID and X.500 DN — and you can paste your own namespace UUID to carve out a private space. Two honest caveats. First, v5 is one-way but not secret: anyone who can guess the name reproduces the UUID, so never treat a v5 as an unguessable token. Second, the name is hashed as UTF-8, so café written as one é and as e+combining-accent are different names and produce different UUIDs — normalise your input first if that matters. This tool ships v5 only: the older v3 uses MD5, which WebCrypto does not provide, and hand-rolling a broken hash is not worth it — RFC 9562 recommends v5 over v3 regardless.

ULIDs: sortable ids in 26 characters

The ULID mode makes a different 128-bit identifier that solves the same problem as UUID v7 — time-sortable, safe to mint anywhere — in a more compact spelling. A ULID is 26 characters of Crockford base32, an alphabet of the digits and uppercase letters that deliberately drops I, L, O and U so ids cannot be misread as 1 or 0 and never spell accidental words. The layout is two fixed fields:

Because the timestamp leads, plain string sorting orders ULIDs by creation time, just like v7 — but at 26 characters with no hyphens, a ULID is 10 characters shorter than a UUID's text form and drops into URLs and file names cleanly. The 80 random bits per id come from crypto.getRandomValues, the same CSPRNG as the UUIDs on this page. Both are 128 bits, so a ULID fits the same BINARY(16) column a UUID does; it simply is not an RFC 9562 UUID — it has no version or variant bits.

The honest limit: this tool generates plain-spec ULIDs. The ULID spec sketches an optional "monotonic" scheme that increments the random field for ids minted inside one millisecond; that scheme is not implemented here, so ULIDs created in the same millisecond are not ordered relative to each other — only the millisecond prefix sorts. If you need strict ordering inside a single millisecond, use a database sequence. And like v7, a ULID broadcasts its creation time to anyone who reads it — the timestamp decode on the Validate tab is the proof — so never use one where minting time must stay private. The randomness is from a CSPRNG, but a ULID is an identifier, not a secret or a security token.

Validating and inspecting a UUID or ULID

The Validate tab answers the everyday question "is this actually a UUID, and what kind?". Paste any value — canonical, hyphen-free, braced {…}, a urn:uuid: string, or a 26-character ULID — and it reports valid or invalid, the version, and the variant (for a ULID, its two-field layout and the exact millisecond it encodes). It is honest about failure: a value of the wrong length, one containing a non-hex character, or one whose variant digit is not 8/9/a/b is flagged invalid rather than quietly accepted (the all-zero Nil and all-one Max UUIDs are recognised as valid special values). For a v7 it goes further and decodes the leading 48 bits back into the exact Unix-millisecond timestamp — so you can read the creation time of a record straight from its primary key, which is also a reminder that v7 keys are not opaque.

Worked example: the format toggles

Pick v4 and a count of 3 and you get three independent lines like the block below. The format chips then reshape every line at once, without generating new randomness:

The hyphen-free 32-character form is handy for URL slugs and object-storage keys; the braced form is the exact shape the Windows registry and many C#/COM APIs expect. All four represent the identical 128-bit value — the punctuation and case are cosmetic.

How unlikely is a collision?

With 122 random bits a v4 UUID has about 5.3 × 10^36 possible values. By the birthday bound you would need to generate roughly 2.7 × 10^18 of them before the odds of any two matching reach 50%. Generate a billion per second and that is about 85 years of continuous work, which is why UUIDs are treated as unique in practice. The honest caveat: this only holds when the randomness is good. This page uses crypto.getRandomValues, a cryptographically secure generator; a library built on Math.random would give you neither these odds nor unpredictability. v7 has 74 random bits per millisecond, so two ids minted in the same millisecond still collide only about 1 in 10^22.

Storing UUIDs without wasting space

A UUID is 16 bytes, but its text form is 36 characters. Storing it as CHAR(36) therefore costs more than twice the raw size and bloats every index that references it. Prefer a native type where one exists — PostgreSQL's uuid, or BINARY(16) in MySQL and SQL Server — and keep the 36-character text only for logs, APIs and anywhere a human reads the value.

Gotchas and honest limits

v7 leaks its creation time. The embedded timestamp is not a secret — do not use v7 (or v1) where the moment of creation must stay private, or as an unguessable capability URL. A UUID is an identifier, not a password: even an unguessable v4 becomes public the instant it lands in a log or a link. Comparisons are case-insensitive by spec but string equality is not — normalise to lowercase (this tool's default) before comparing. And a UUID buys you uniqueness, not brevity or ordering-for-humans: if you need short, readable, or strictly sequential ids, a database sequence or a scheme like a short-code may serve better.

Common mistakes

Using random v4 as a clustered primary key. On InnoDB or SQL Server the clustered index is physically ordered by the key, so random v4 inserts fragment the table and slow writes — reach for v7 (or an auto-increment) there. Storing as VARCHAR(36). It works, but doubles storage and index size versus binary. Trusting a Math.random UUID library. The collision and secrecy guarantees evaporate without a CSPRNG. Case-sensitive lookups. Mixing an uppercase-storing service with a lowercase-storing one makes equal UUIDs look different. Treating v1/v7 as opaque. They are not — they broadcast a timestamp, so never rely on them to hide ordering or timing.

Want the full picture? Learn more in UUIDs Explained → — a first-principles walkthrough of the 128-bit layout, a field-by-field dissection of the version and variant digits, v4 vs v7, and the birthday-bound collision math worked out honestly.