What a UUID v5 is and why it is deterministic
A UUID v5 is a 128-bit identifier defined in RFC 4122 that, unlike the random v4, is computed from two inputs: a namespace (which is itself a UUID) and a name (any text). The algorithm applies SHA-1 to the concatenation of both, so the same namespace with the same name always produces the same UUID — in any language, on any machine, today and ten years from now. That reproducibility is gold for several real-world problems: deduplication (two systems that see the same record generate the same ID without coordinating), stable cache keys, data migrations where you need to regenerate IDs without breaking references, and reproducible IDs in tests and pipelines. The namespace prevents collisions between different domains: "john" as a user and "john" as a product yield different UUIDs if you use different namespaces.
How it is computed (the algorithm step by step)
The RFC 4122 algorithm is simple: take the 16 bytes of the namespace UUID, append the UTF-8 bytes of the name, and compute the SHA-1 of the whole thing. Of the 20 hash bytes, the first 16 are used; then the version nibble is forced to 5 in byte 6 and the variant bits (10) in byte 8, and the result is formatted as 8-4-4-4-12. For example, with the DNS namespace and the name www.example.com the result is always 2ed6657d-e927-568b-95e1-2665a8aea6a2 — the official example from RFC 9562 (the revision of RFC 4122), which you can verify above or in Python with uuid.uuid5(uuid.NAMESPACE_DNS, 'www.example.com'). This tool computes the SHA-1 with crypto.subtle, the browser's native crypto API, so nothing leaves your device.
v5 is not for everything: when another version fits better
If what you need is a fresh unique ID with no input at all (the most common case in databases and APIs), you want a random v4 or a time-sortable v7: for that we have our UUID generator, which produces v4 and v7 individually or in bulk. Use v5 only when the property you are after is that the same data always produces the same ID.
UUID version comparison
| Version | Data source | Deterministic | Hash | When to use it |
|---|---|---|---|---|
| v1 | Timestamp + MAC address | No | — | Legacy systems; leaks the machine's MAC (privacy issue) |
| v3 | Namespace + name | Yes | MD5 | Only for compatibility with old systems; prefer v5 |
| v4 | Random (CSPRNG) | No | — | The general case: unique IDs with no coordination between systems |
| v5 | Namespace + name | Yes | SHA-1 | Reproducible IDs: deduplication, cache keys, migrations |
| v7 | Timestamp + random | No | — | Time-sortable database keys (index-friendly) |
The 4 standard RFC 4122 namespaces
| Namespace | UUID | What kind of name it is for |
|---|---|---|
| DNS | 6ba7b810-9dad-11d1-80b4-00c04fd430c8 | Domain names (e.g. www.example.com) |
| URL | 6ba7b811-9dad-11d1-80b4-00c04fd430c8 | Full URLs (e.g. https://example.com/a) |
| OID | 6ba7b812-9dad-11d1-80b4-00c04fd430c8 | ISO object identifiers (e.g. 1.3.6.1.4.1) |
| X.500 | 6ba7b814-9dad-11d1-80b4-00c04fd430c8 | Directory distinguished names (LDAP/X.500 DNs) |
If your names do not fit any standard category, generate a UUID v4 once, pin it as a constant in your project and use it as your own namespace via the "Custom" option.