GUID / UUID V5 - Name-Based Identifier (SHA-1 Hash)

GUID / UUID v5 is a name-based identifier that generates deterministic GUIDs / UUIDs by hashing a namespace UUID and a name using the SHA-1 algorithm. The same namespace and name combination always produces the same GUID / UUID, making it useful for stable, repeatable identifiers derived from existing data. V5 is the modern, preferred alternative to v3, which uses the weaker MD5 algorithm.

Recommended for name-based GUIDs / UUIDs: v5 is the preferred choice for deterministic, name-based identifiers. It uses SHA-1 instead of MD5, making it more robust than v3 for non-adversarial scenarios.
SHA-1 security note: While SHA-1 is stronger than MD5, it is no longer considered fully secure for cryptographic purposes. V5 GUIDs / UUIDs should not be used in adversarial security contexts or where collision resistance is critical.

Version status and history

GUID / UUID v5 was defined in the original GUID / UUID specifications around 1997 and standardized in RFC 4122 in July 2005.

V5 is fully supported and has no deprecation concerns in both RFC 4122 and RFC 9562. It remains the recommended option for name-based, deterministic GUID / UUID generation, particularly when upgrading from v3.

For non-deterministic identifiers, consider v4 (random) or v7 (time-ordered).

Advantages of GUID / UUID v5

  • Deterministic generation: the same inputs always produce the same GUID / UUID, which is ideal for idempotent operations and stable mappings.
  • No coordination required: GUIDs / UUIDs can be generated independently without shared state or a central authority.
  • Namespace isolation: identical names in different namespaces produce different GUIDs / UUIDs, preventing collisions across different domains.
  • More robust than v3: uses SHA-1 instead of MD5, avoiding known collision vulnerabilities of MD5.
  • Standardized behavior: generation rules are clearly defined and consistent across platforms.
  • Useful for data modeling: convenient for deriving GUIDs / UUIDs from existing identifiers (URLs, DNS names, usernames) or content hashes.
  • Interoperability: widely supported in GUID / UUID libraries and compatible with RFC 4122 implementations.

Warnings and considerations

  • SHA-1 is not fully secure: while stronger than MD5, SHA-1 is considered weak for cryptographic security and should not be relied on for collision resistance in adversarial scenarios.
  • Predictable values: anyone who knows the namespace and name can reproduce the GUID / UUID. This is by design, but means v5 should not be used as secrets.
  • Not a security token: v5 GUIDs / UUIDs must not be used as access tokens, API secrets, passwords, or cryptographic keys.
  • No time ordering: v5 GUIDs / UUIDs contain no timestamp and do not sort by creation time. For time-based sorting, use v7.
  • Input stability required: changes in name encoding, normalization or namespace will produce completely different GUIDs / UUIDs. Maintain consistent encoding standards.

Technical details

Generation algorithm: GUID / UUID v5 is computed by concatenating the binary representation of the namespace UUID (16 bytes) and the name (as UTF-8 bytes), then hashing the result using SHA-1. The first 128 bits of the SHA-1 output (which produces 160 bits) are used as the base GUID / UUID, with version and variant bits overwritten.

Bit layout: GUID / UUID v5 follows the standard 128-bit layout with canonical string format (8-4-4-4-12). The value is derived from SHA-1 hash output, with reserved bits to indicate the version (5) and variant.

Deterministic generation: GUID / UUID v5 is fully deterministic. Given the same namespace and name, the same GUID / UUID will always be generated, regardless of when or where it is created.

Field structure (SHA-1 hash-based)

Field                        Bits  Hex Digits  Description
─────────────────────────────────────────────────────────────────────────
hash_low                     32    8           Low 32 bits of SHA-1 hash
hash_mid                     16    4           Middle 16 bits of SHA-1 hash
hash_hi_and_version          16    4           High 12 bits of SHA-1 hash + 4-bit version (0101)
hash_seq_hi_and_reserved     8     2           2-bit variant (10) + 6 bits from SHA-1 hash
hash_seq_low                 8     2           8 bits from SHA-1 hash
hash_node                    48    12          48 bits from SHA-1 hash

Hash algorithm: SHA-1 produces a 160-bit (20-byte) output, but only the first 128 bits are used. The version bits (bits 12-15 of hash_hi_and_version) are set to 0101 (5 in hex). The variant bits (bits 6-7 of hash_seq_hi_and_reserved) are set to 10 for RFC 4122 compliance. All other bits come directly from the SHA-1 hash output.

Namespaces: RFC 4122 defines well-known namespace GUIDs / UUIDs:
• DNS: 6ba7b810-9dad-11d1-80b4-00c04fd430c8
• URL: 6ba7b811-9dad-11d1-80b4-00c04fd430c8
• OID: 6ba7b812-9dad-11d1-80b4-00c04fd430c8
• X.500: 6ba7b814-9dad-11d1-80b4-00c04fd430c8
Custom namespaces can also be used for application-specific requirements.

Try our GUID / UUID Inspector to see the hash-derived structure of v5 GUIDs / UUIDs.

Format and structure

GUID / UUID v5 uses the standard 8-4-4-4-12 canonical format with 32 hexadecimal digits separated by hyphens (36 characters total).

Canonical format:  8-4-4-4-12
Example (v5):      987fbc97-4bed-5078-8f07-9141ba07c9f3
Layout:            xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
                                 ^    ^
                                 |    └─ N = Variant: is typically 8, 9, a or b (RFC variant)
                                 └────── M = Version: first hex digit of the 3rd group is "5" for v5

Practical rule: in the canonical string, the version is encoded as the first hex digit of the third group. For v5 it is 5. The variant is indicated by the high bits of the fourth group (often rendered as 8-b in hex for the common standard variant). The remaining bits are derived from the SHA-1 hash.

Frequently Asked Questions

GUID / UUID v5 is a name-based identifier that generates deterministic UUIDs by hashing a namespace UUID and a name using SHA-1. The namespace (a predefined or custom UUID) and name (a string) are concatenated in binary form and hashed, producing a consistent 128-bit GUID / UUID. The same namespace and name always produce the same GUID / UUID, making it ideal for stable, repeatable identifiers.

Use v5 when you need deterministic, name-based identifiers for stable mappings, idempotent operations or deriving GUIDs / UUIDs from existing data (URLs, DNS names, usernames). It's ideal for API integration, content-addressable systems, and scenarios where the same input should always produce the same GUID / UUID. For random identifiers, use v4. For time-based ordering, use v7.

RFC 4122 defines four standard namespaces:
  • DNS: 6ba7b810-9dad-11d1-80b4-00c04fd430c8 (for domain names)
  • URL: 6ba7b811-9dad-11d1-80b4-00c04fd430c8 (for URLs)
  • OID: 6ba7b812-9dad-11d1-80b4-00c04fd430c8 (for ISO OID)
  • X.500: 6ba7b814-9dad-11d1-80b4-00c04fd430c8 (for X.500 DNs)
You can also create custom namespace GUIDs / UUIDs for application-specific purposes.

Both v5 and v3 are name-based and deterministic, but v5 uses SHA-1 while v3 uses MD5. SHA-1 is more secure and less vulnerable to collision attacks than MD5, making v5 the recommended choice for new systems. The generation algorithm is identical except for the hash function, so migrating from v3 to v5 requires regenerating GUIDs / UUIDs with the same namespace/name pairs.

Yes, that's the core feature of v5 being deterministic. If two systems use the same namespace GUID / UUID and the same name, they will independently generate identical GUIDs / UUIDs. This is useful for creating stable identifiers across distributed systems without coordination, but it also means the GUIDs / UUIDs are predictable and should not be used as secrets.

SHA-1 is no longer considered fully secure for cryptographic purposes and has known collision vulnerabilities. However, for non-adversarial UUID generation, it provides sufficient collision resistance. V5 should not be used in security-sensitive contexts where collision resistance is critical, such as digital signatures or certificate validation. For general-purpose stable identifiers, v5 remains practical and widely used.

The RFC specifies that names should be encoded consistently, typically as UTF-8 bytes. However, implementations may vary. To ensure interoperability, document and standardize how your application encodes names (character encoding, Unicode normalization). Inconsistent encoding will produce different GUIDs / UUIDs even for the "same" name. When generating v5 GUIDs / UUIDs for URLs or DNS names, use lowercase and follow normalization standards.

Yes, v5 can be used as a database primary key, especially when you need stable identifiers derived from existing data. Unlike random v4 UUIDs, v5 provides idempotency. Inserting the same data multiple times generates the same GUID / UUID, preventing duplicates. However, be aware that v5 GUIDs / UUIDs are not time-ordered and may cause index fragmentation. For better database performance with sequential inserts, consider v7.

Most languages have UUID library support for v5:
  • JavaScript/Node.js: Use uuid npm package: uuid.v5(name, namespace)
  • Python: import uuid; uuid.uuid5(uuid.NAMESPACE_DNS, 'example.com')
  • Java: Use java.util.UUID.nameUUIDFromBytes() with SHA-1 (requires manual implementation)
  • C#: Use third-party libraries like Faithlife.Utility or implement SHA-1 hashing
  • Go: uuid.NewV5(namespace, name) (with google/uuid package)
  • Rust: Uuid::new_v5(namespace, name) (with uuid crate)

Conclusion

GUID / UUID v5 is the preferred choice when you need deterministic, name-based identifiers without relying on randomness or coordination. It uses SHA-1 instead of MD5, making it more robust than v3 for most practical applications. While it should not be used for security-sensitive purposes, it is well-suited for stable mappings, idempotent operations, and derived identifiers in modern systems.

Learn more

These articles expand on related concepts, formats and practical considerations.

Disclaimer: All information is provided for general educational and technical reference only. While we aim to keep the content accurate, current and aligned with published standards. No guarantees are made regarding completeness, correctness or suitability for any specific use case.
GUID / UUID specifications, RFCs, best practices, security guidance, database behavior and ecosystem conventions (including cloud platforms and third-party identifier formats) may change over time or differ by implementation. Examples, recommendations, and comparisons are illustrative and may not apply universally.
This content should not be considered legal, security, compliance or architectural advice. Before making critical design, security, or production decisions, always consult the latest official standards and documentation (such as RFC 4122, RFC 9562 and vendor-specific references).
Always evaluate behavior in your own environment.