UUID v5 Generator

Generate a UUID version 5 — a deterministic, name-based identifier derived by hashing a namespace and a name with SHA-1. Unlike random v4 UUIDs, the same namespace and name always produce the same UUID, which makes v5 ideal for stable IDs you can recompute instead of store. Pick one of the standard namespaces (DNS, URL, OID, X.500) or supply your own namespace UUID, type a name, and get the result instantly — computed in your browser, with the version and variant bits set per RFC 4122.

How to use the UUID v5 Generator

Choose a namespace and type a name. The four built-in namespaces are the standard ones defined in RFC 4122: use DNS for domain names, URL for web addresses, OID for ISO object identifiers and X.500 for directory distinguished names. If your IDs live in some other space — a tenant, a product line, an internal scheme — pick Custom and paste your own namespace UUID, which you generate once (a random v4 UUID works) and then reuse. The result updates as you type, and the breakdown shows the namespace and name that went into it.

The UUID is computed by concatenating the 16 bytes of the namespace with the UTF-8 bytes of the name, hashing that with SHA-1, taking the first 16 bytes of the digest, and setting the version nibble to 5 and the variant bits per the spec. Because the process is fully deterministic, the same namespace and name will always give you the same UUID — on any machine, in any language, today or next year. That's the property that makes v5 useful: you can derive a stable identifier from data you already have rather than generating a random one and storing the mapping. Everything runs locally, so the names you enter never leave your browser.

Deterministic UUIDs: v5 versus v4

A UUID is a 128-bit identifier designed to be unique without a central authority handing out values, and the standard defines several versions that achieve that in different ways. The most familiar, version 4, is simply random: generate 122 bits of randomness and the chance of a collision is negligible. Version 5 takes the opposite approach — it is name-based and deterministic, computed by hashing a namespace identifier together with a name using SHA-1. The same inputs always yield the same output, which is the entire point.

That determinism unlocks a different design pattern. With v4 you generate an ID and must store the link between it and whatever it represents; with v5 you can derive the ID from the thing itself whenever you need it. Given a user's email, a document's URL, or a product's SKU, you can compute its UUID on demand, in any service, without a database lookup or a shared sequence — and two systems that agree on the namespace will independently arrive at the identical UUID. The namespace prevents collisions between different kinds of names: the name "example" under the DNS namespace produces a completely different UUID than "example" under a URL or custom namespace, so you can safely reuse names across domains. The standard namespaces (DNS, URL, OID, X.500) cover common cases, and you can mint your own namespace UUID to carve out a private space.

The trade-offs are worth understanding. Because v5 is deterministic, it is not secret or unpredictable — anyone who knows the namespace and name can compute the same UUID, so it must never be used as a security token or to hide information. It also inherits SHA-1 as its hash, which is fine for generating identifiers (collision resistance isn't a security property here) but is the reason no v5-with-SHA-256 variant is widely deployed. Within those limits, v5 is the right tool whenever you want reproducible, collision-resistant IDs derived from existing data: content addressing, idempotency keys, mapping external identifiers into your own ID space, or any situation where "the same input should always get the same ID" is a feature rather than a risk.

Common use cases

  • Stable derived IDs. Compute a fixed UUID from an email, URL or SKU instead of storing a random one.
  • Idempotency keys. Derive the same key from the same request so retries don't create duplicates.
  • Cross-system agreement. Let independent services arrive at the identical UUID from shared inputs.
  • Mapping external identifiers. Fold third-party IDs into your own UUID namespace deterministically.

Frequently asked questions

How is a v5 UUID different from a v4?
Version 4 is random — every call produces a new, unpredictable value. Version 5 is deterministic and name-based: it hashes a namespace and a name with SHA-1, so the same inputs always produce the same UUID. Use v4 when you want uniqueness with no relationship to the data; use v5 when you want a reproducible ID derived from the data.

What is the namespace for?
The namespace scopes the name so the same name in different contexts produces different UUIDs. "example" under the DNS namespace is a different UUID than "example" under URL or a custom namespace, which lets you reuse names safely across domains. RFC 4122 defines DNS, URL, OID and X.500 namespaces, and you can create your own.

Will I get the same UUID as other libraries?
Yes. The computation follows RFC 4122 exactly — concatenate the namespace bytes and UTF-8 name bytes, hash with SHA-1, take 16 bytes, set the version and variant bits — so any conforming implementation produces the identical UUID for the same namespace and name. This tool matches the standard test vectors.

Can I use a v5 UUID as a secret or token?
No. Because it is deterministic, anyone who knows the namespace and name can compute the same value, so it provides no secrecy or unpredictability. Use it as an identifier, never as an authentication token, API key or anything that needs to be hard to guess.

Why version 5 and not version 3?
Version 3 is the same idea but uses MD5 instead of SHA-1. Version 5 is generally preferred because SHA-1 is the more modern of the two hashes the standard allows; both are fine for generating identifiers since collision resistance is not a security requirement here. This tool implements v5 (SHA-1).