GUID / UUID V3 - Name-Based Identifier (MD5 Hash)

GUID / UUID v3 is a name-based identifier that generates deterministic GUIDs / UUIDs by hashing a namespace UUID and a name using the MD5 algorithm. The same namespace and name combination always produces the same GUID / UUID, making it useful for stable, repeatable identifiers derived from existing data.

Security warning: GUID / UUID v3 uses MD5, which is cryptographically broken. It should not be used where collision resistance or security matters. For name-based GUIDs / UUIDs, use v5 (SHA-1) instead.

Version status and history

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

V3 is not formally deprecated and remains valid in both RFC 4122 and RFC 9562. However, it is discouraged for new systems because it relies on MD5, which has known collision vulnerabilities and is no longer considered cryptographically secure.

For modern designs requiring name-based UUIDs, v5 (which uses SHA-1) is the recommended alternative. If you don't need deterministic identifiers, use v4 for randomness or v7 for time-ordered IDs.

Advantages of GUID / UUID v3

  • Deterministic output: the same namespace and name always generate the same GUID / UUID.
  • No coordination required: identifiers can be generated independently without shared state or central services.
  • Name-derived identity: useful for mapping existing identifiers (such as URLs or usernames) into a GUID / UUID form.
  • Globally unique per namespace: uniqueness is guaranteed as long as the namespace/name combination is unique.
  • Standardized behavior: generation rules are clearly defined in the UUID specification.
  • Wide support: v3 is supported by most GUID / UUID libraries.

Warnings for GUID / UUID v3

  • Uses cryptographically broken MD5: MD5 has known collision vulnerabilities and should not be used where security or collision resistance matters.
  • Predictable identifiers: anyone who knows the namespace and name can reproduce the GUID / UUID.
  • Not suitable for secrets: v3 GUIDs / UUIDs must never be used as authentication tokens or unguessable IDs.
  • No time ordering: v3 UUIDs have no temporal component and do not sort by creation time.
  • Legacy choice: for new systems, v5 (SHA-1) is preferred for name-based GUIDs / UUIDs.
  • Implementation differences: the way names are encoded (UTF-8, UTF-16, etc.) can affect the resulting GUID / UUID if not standardized.

Technical description

Bit layout (practical view): GUID / UUID v3 follows the standard 128-bit layout and canonical string format 8-4-4-4-12. The GUID / UUID is derived by computing an MD5 hash over the concatenation of namespace UUID (binary) + name (bytes).

Generation algorithm: The namespace UUID is converted to its binary representation (16 bytes), concatenated with the name as a byte sequence, then hashed using MD5. The resulting 128-bit hash is used as the GUID / UUID, with specific bits overwritten for version and variant.

Fields (what exists): the 128-bit MD5 hash output is used as the base value. Certain bits are then overwritten to indicate the version (3) and the variant (RFC-defined layout). No timestamp, counter or node identifier exists in v3—the entire value is hash-derived.

Deterministic generation: GUID / UUID v3 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 (MD5 hash-based)

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

Hash algorithm: MD5 produces a 128-bit (16-byte) output. The version bits (bits 12-15 of hash_hi_and_version) are set to 0011 (3 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 MD5 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 v3 UUIDs.

Format and structure

GUID / UUID v3 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 (v3):      3d813cbb-47fb-32ba-91df-831e1593ac29
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 "3" for v3

Practical rule: in the canonical string, the version is encoded as the first hex digit of the third group. For v3 it is 3. 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 MD5 hash.

Frequently Asked Questions

GUID / UUID v3 is a name-based identifier that generates deterministic UUIDs by hashing a namespace UUID and a name using MD5. The namespace (a predefined or custom UUID) and name (a string) are concatenated and hashed, producing a consistent 128-bit GUID / UUID. The same namespace and name always produce the same GUID / UUID.

No, it's discouraged. UUID v3 uses MD5, which is cryptographically broken and vulnerable to collision attacks. For name-based GUIDs / UUIDs, use v5 (SHA-1) instead. For non-deterministic needs, use v4 for randomness or v7 for time-ordered IDs.

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.

MD5 has known collision vulnerabilities, meaning it's possible (though difficult) to find two different inputs that produce the same hash output. While this doesn't make v3 GUIDs / UUIDs completely unusable, it creates theoretical collision risks that v5 (SHA-1) addresses better. For security-sensitive applications, MD5's weaknesses make v3 unsuitable.

Yes, that's the point of v3 being deterministic. If two systems use the same namespace 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.

Using a different namespace UUID with the same name will produce a completely different GUID / UUID. Namespaces act as "buckets" to partition the UUID space, the same name in different namespaces generates different GUIDs / UUIDs. This allows different applications or domains to use the same names without collision risks.

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, normalization). Inconsistent encoding will produce different GUIDs / UUIDs even for the "same" name.

No, GUID / UUID v3 is not formally deprecated in RFC 4122 or RFC 9562. However, it is discouraged for new systems due to MD5's cryptographic weaknesses. V3 remains valid for legacy compatibility and is still supported by most GUID / UUID libraries, but v5 is recommended for new name-based GUID / UUID requirements.

Use v3 only for compatibility with existing systems that specifically require MD5-based GUIDs / UUIDs. For all new implementations requiring name-based GUIDs / UUIDs, use v5 (SHA-1) instead. While SHA-1 also has known weaknesses, it's still significantly more robust than MD5 and is the current standard for deterministic name-based GUIDs / UUIDs.

Conclusion

GUID / UUID v3 provides deterministic, name-based identifiers that are useful for stable mappings and legacy interoperability. However, because it relies on MD5 and produces predictable values, it is discouraged for new systems. When name-based GUIDs / UUIDs are required today, v5 (SHA-1) is the preferred alternative.

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.