UUID v5 Generator

Enter a namespace UUID (DNS, URL, or your own) and a name, and get the UUID v5 that combination always produces — unlike v4, which is random every time, v5 is a one-way, repeatable derivation, useful for generating a stable ID from something like a URL or an email address without having to store a mapping anywhere.

Deterministic: same namespace + name always gives the same UUID

Standard DNS, URL, OID and X.500 namespaces, or a custom one

SHA-1-based per RFC 4122/9562, verified against the reference test vector

Runs fully client-side

How to generate a UUID v5

Pick a namespace

Use a standard one (DNS, URL) if the name is that kind of thing, or supply your own namespace UUID for anything else.

Enter the name

A domain, a URL, an email — whatever string should always map to the same UUID.

Copy the result

Running the exact same namespace and name through this again will always produce the identical UUID.

Why anyone would want a UUID that is not random#

A v4 UUID is random on purpose — useful as a unique identifier with no relationship to anything else. v5 solves a different problem: turning an existing piece of data (a URL, a domain, an email) into a stable UUID without keeping a lookup table anywhere. Two independent systems that both compute uuidV5(sameNamespace, "[email protected]") get the identical UUID without ever talking to each other — the value is a pure function of its inputs, not a lookup.

What the namespace is actually for#

The namespace exists so that the same name string produces a different UUID depending on what kind of thing it names — uuidV5(DNS_NAMESPACE, "example.com") and uuidV5(URL_NAMESPACE, "example.com") are guaranteed to differ, even though the name text is identical, because the namespace UUID is mixed into the hash before the name. The four standard namespaces (DNS, URL, OID, X.500) exist for interoperability with other systems generating v5 UUIDs for the same kinds of data; a custom namespace works identically for anything that does not fit those categories — pick any UUID and use it consistently.

Why this uses SHA-1, and why that is fine here#

SHA-1 is considered broken for cryptographic purposes — an attacker can construct two different inputs with the same hash — but that weakness is irrelevant to what v5 uses it for. Nothing here depends on SHA-1 being uncrackable; it is used purely as a well-distributed mixing function to turn (namespace, name) into 128 semi-random-looking bits, not as a security mechanism. The RFC deliberately kept SHA-1 in the v5 algorithm rather than requiring implementations to migrate to a newer hash, specifically because collision resistance was never the property v5 relies on.

Frequently asked questions

How is this different from a regular (v4) UUID?

A v4 UUID is random every time you generate one. A v5 UUID is deterministic — the same namespace and name always produce the identical UUID, useful for deriving a stable ID from existing data without keeping a lookup table.

Why does the namespace matter if the name is the same?

The namespace is mixed into the hash before the name, so the same name text under two different namespaces is guaranteed to produce two different UUIDs. This lets "example.com" as a DNS name and "example.com" as a URL map to different, unambiguous UUIDs.

Is it a problem that UUID v5 uses SHA-1, which is considered broken?

No — SHA-1's known weakness is that an attacker can craft two colliding inputs, which matters for security-sensitive uses like digital signatures. UUID v5 only uses SHA-1 as a mixing function to spread (namespace, name) across 128 bits, a property SHA-1 still provides fine.

Is my namespace or name data sent anywhere?

No. The hash is computed entirely in your browser using the Web Crypto API — nothing is uploaded.

Related tools

Developers