Create a deterministic UUID from a namespace and an exact name using the SHA-1-based UUIDv5 algorithm.
Result
The result receives keyboard focus after successful single generation.
UUIDv5 structure
sha1_high
First 32 retained SHA-1 bits.
sha1_mid
Next 16 retained SHA-1 bits.
version
Next 16 bits; the high nibble is overwritten with 0101.
variant
Next 16 bits; the two high bits are overwritten with 10.
sha1_low
Final 48 retained hash bits.
0 names processed
Name
UUID
Keyboard shortcut: Ctrl/Cmd + Enter.
Use this UUIDv5 in code
These snippets use the selected namespace and exact name. Expected result:
How UUIDv5 is calculated
RFC 9562 supersedes RFC 4122 and retains the compatible UUIDv5 algorithm and well-known namespaces.
Convert the namespace UUID to its 16 network-order bytes.
UTF-8 encode the canonical name and append those bytes to the namespace bytes.
Compute the 160-bit SHA-1 digest.
Retain the leftmost 128 bits, discarding the rightmost 32 bits.
Set the four version bits to 0101 and the two variant bits to 10.
Serialize the 128-bit value in standard UUID form.
Worked RFC 9562 Appendix A.4 test vector
Namespace
6ba7b810-9dad-11d1-80b4-00c04fd430c8 (DNS)
Name
www.example.com
SHA-1 digest
2ed6657de927468b55e12665a8aea6a22dee3e35
Leftmost 128 bits
2ed6657d-e927-468b-55e1-2665a8aea6a2
Overwritten bits
4 → 5 for version; high bits of 55 → 10, producing 95 for the variant octet.
Discarded 32 bits
2dee3e35
Final UUID
2ed6657d-e927-568b-95e1-2665a8aea6a2
Practical UUIDv5 guidance
Suitable uses
Stable IDs for canonical URLs, imported records, fixtures, resources shared across services, and migrations where the same source key must reproduce the same identifier.
Unsuitable uses
Secrets, passwords, signatures, authentication tokens, unpredictable IDs, or identifiers whose creation time must be sortable. UUIDv5 names can be guessed and tested.
Namespace design
Use a built-in namespace only when its naming rules fit. For an application-owned domain, generate one namespace UUID, document its meaning and version, and keep it stable.
Canonicalization
Specify case, whitespace, Unicode normalization, URL scheme, ports, trailing slashes, query ordering, and DNS trailing-dot policy before generating IDs. Apply that policy identically in every system.
Collisions
Accidental UUIDv5 collisions are extremely unlikely, but hashes do not prove that two original byte strings were identical. Enforce uniqueness and retain or verify the canonical source key where collisions matter.
Cross-system consistency
Share the namespace UUID, UTF-8 encoding, canonicalization rules, and a test vector. Compare expected UUIDs in automated tests before exchanging production identifiers.
Generation occurs locally in browser JavaScript; names and namespace values are not sent to a server by this tool. SHA-1 is required for interoperable UUIDv5 identifiers, but it should not be used for signatures, passwords, authentication, or adversarial security decisions.
Last reviewed: .
UUIDv5 FAQ
Is UUIDv5 random?
No. UUIDv5 is deterministic: it hashes a namespace UUID and name with SHA-1, then sets the version and variant bits.
Will the same namespace and name always produce the same UUIDv5?
Yes, when both systems use the same namespace UUID and exactly the same name bytes. Different case, whitespace, encoding, normalization, URL spelling, or DNS trailing dots can change the result.
Are UUIDv5 names case-sensitive?
Yes. This tool UTF-8 encodes the entered string exactly, so Example.com and example.com produce different byte sequences and normally different UUIDs.
How do I choose or create a custom namespace?
Use a standard namespace when its naming rules fit. For application-owned identifiers, generate and permanently record a UUID for the namespace, then use that same UUID in every system.
Does SHA-1 make UUIDv5 unsafe?
SHA-1 is required for interoperable UUIDv5 identifiers. UUIDv5 is suitable for stable identifiers, but not for signatures, passwords, authentication tokens, or adversarial security decisions.
Can a UUIDv5 be reversed to reveal the name?
Not directly. UUIDv5 stores a truncated, bit-modified hash rather than the original name, although predictable names can still be guessed and checked.
How should UUIDv5 collisions be handled?
Accidental collisions are extremely unlikely but possible. Systems that require absolute uniqueness should enforce a unique constraint, compare the canonical source key on conflict, and use a documented resolution policy.
When should I choose UUID v3, v4, v7, or v8 instead?
Choose v3 only for MD5-based compatibility, v4 for random opaque IDs, v7 for time-ordered IDs, and v8 for a documented application-specific format. Choose v5 for interoperable name-based IDs.
