GUID / UUID V8 - Custom / Application-Defined Identifier (Experimental)

GUID / UUID v8 is a flexible, application-defined identifier format that provides a standardized container for custom schemes. Unlike other GUID / UUID versions, v8 does not prescribe how most bits are generated, allowing applications to define their own internal structure while producing valid GUID / UUID strings.

Experimental and Custom: GUID / UUID v8 is designed for advanced use cases where predefined versions (v4 and v7) don't fit. It requires careful design and documentation, as uniqueness and ordering guarantees depend entirely on the application's implementation.

Version status and history

GUID / UUID v8 was officially standardized in RFC 9562 in May 2024, first appearing around 2022 in draft specifications.

V8 is an experimental version intended for application-specific identifier schemes. It exists to support custom designs that need to fit into the GUID / UUID ecosystem (databases, APIs, tooling) without pretending to follow time-based, random or name-based semantics.

For standard use cases, consider v4 (random) or v7 (time-ordered, Unix milliseconds).

Advantages of GUID / UUID v8

  • Maximum flexibility: applications can define their own bit layout, encoding schemes, or semantic meanings without being constrained by predefined structures.
  • Standards-compliant container: still conforms to the UUID string format (8-4-4-4-12) and variant rules, ensuring compatibility with existing GUID / UUID parsers.
  • Future-proof design: enables new UUID-like identifier designs without requiring new version numbers or RFC updates.
  • Ecosystem compatibility: works with existing GUID / UUID databases, APIs, serialization formats and tooling that expect standard GUID / UUID shapes.
  • Explicit intent signaling: clearly indicates that the GUID / UUID does not follow predefined semantics like v1-v7, preventing misinterpretation.
  • Custom ordering strategies: applications can embed custom sortability, sharding keys or hierarchical structures as needed.

Warnings and considerations

  • No guaranteed uniqueness model: uniqueness depends entirely on the application's design and implementation. Poor designs can lead to collisions.
  • No implied ordering or monotonicity: v8 does not guarantee time ordering or sortability unless explicitly designed and documented by the application.
  • Opaque to external systems: other systems cannot infer meaning from the bits without application-specific documentation or context.
  • Easy to misuse: without careful design, v8 implementations can produce confusing behavior, poor performance or security issues.
  • Not a security primitive: v8 provides no cryptographic guarantees by itself. Security must be built into the custom design.
  • Documentation burden: requires comprehensive documentation for maintainability and interoperability across teams and systems.
  • Limited ecosystem support: libraries and tools may not provide generation helpers for v8, requiring custom implementation.

Technical details

Bit layout: a GUID / UUID is 128 bits written in a canonical 36-character string format with 32 hexadecimal digits plus 4 hyphens (8-4-4-4-12). For v8, only the version field (set to 8) and the variant field (RFC-defined) are mandatory. All remaining 122 bits are application-defined.

Generation algorithm: the specification does not define any generation algorithm. Applications may encode timestamps, random data, hashes, counters, sharding keys, hierarchical identifiers or any other data structure into the 122 available bits.

Field structure (application-defined)

Field Name                   Bits  Hex Digits  Description
─────────────────────────────────────────────────────────────────────────
custom_a                     48    12          Application-defined (could be timestamp, ID, etc.)
ver                          4     1           4-bit version field (1000 = 8 in hex)
custom_b                     12    3           Application-defined bits
var                          2     ~0.5        2-bit variant field (10 = RFC 4122 variant)
custom_c                     62    ~15.5       Application-defined bits

custom_a (48 bits): the first 48 bits are entirely application-defined. Common uses include timestamps (like v7), node identifiers, shard keys or hierarchical prefixes.

ver (4 bits): the version field is set to 1000 (8 in hex), identifying this as a v8 GUID / UUID.

custom_b (12 bits): 12 application-defined bits immediately following the version field.

var (2 bits): the variant bits are set to 10, indicating RFC 4122 compliance.

custom_c (62 bits): 62 application-defined bits. The application determines the meaning, structure, and generation method for all custom fields.

Try our GUID / UUID Inspector to decode and visualize the version and variant fields of v8 GUIDs / UUIDs.

Format and structure

GUID / UUID v8 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 (v8):      12345678-1234-8abc-9def-0123456789ab
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 "8" for v8

Practical rule: in the canonical string, the version is encoded as the first hex digit of the third group. For v8 it is 8. The variant is indicated by the high bits of the fourth group (often rendered as 8-b in hex for the common standard variant). All other bits should be interpreted according to application-specific rules.

Ordering behavior: v8 GUIDs / UUIDs have no inherent ordering. Any ordering, monotonicity or sortability must be explicitly designed and documented by the application generating them. If time-based ordering is needed, consider using v7 instead.

Frequently Asked Questions

GUID / UUID v8 is a flexible, application-defined identifier format that provides a standardized container (128-bit GUID / UUID shape) for custom schemes. Use v8 when none of the predefined versions (v4 or v7) fit your specific requirements, such as embedding custom sharding keys, hierarchical identifiers or domain-specific structures. For most applications, v4 (random) or v7 (time-ordered) are better defaults.

v4 uses 122 bits of randomness with a well-defined generation algorithm (cryptographically secure random number generator). V8 gives you 122 bits of application-defined data with no prescribed generation method. V4 guarantees collision resistance through randomness. V8's uniqueness depends entirely on your custom design.

Yes, but only if you explicitly design it that way. You could embed a timestamp in the first 48 bits (similar to v7) or use another ordering scheme. However, if time-ordering is your primary goal, use v7 instead. It is standardized, well-understood and has broad library support.

Common use cases include:
  • Sharding keys: Embedding database shard identifiers in the GUID / UUID
  • Hierarchical identifiers: Encoding parent-child relationships or organizational structures
  • Custom sortable schemes: Application-specific ordering beyond timestamps
  • Domain-specific encodings: Embedding business logic, geographic regions or tenant IDs
  • Legacy system integration: Wrapping existing identifier schemes in GUID / UUID format

Uniqueness is entirely your responsibility. Design strategies include: combining timestamps with node IDs or counters, using a portion for randomness, embedding unique shard or partition keys or implementing centralized coordination. Test thoroughly and document your uniqueness guarantees. If you don't need custom semantics, use v4 for proven collision resistance.

Most UUID libraries can parse and validate v8 UUIDs (recognizing the version field as "8"), but few provide generation helpers because v8 is application-defined. You'll typically need to implement your own generation logic. Libraries like Python's uuid module, JavaScript's uuid package, and others can parse v8, but you'll construct the bytes yourself according to your custom design.

Yes, as long as your custom design ensures uniqueness and considers database performance. If you design v8 with time-ordering (like v7), it can reduce index fragmentation. Random or poorly designed v8 schemes may perform worse than v1-v7. For standard database keys, prefer v7 (time-ordered) or v4 (random) unless you have specific requirements.

Generate v8 by constructing 128 bits with your custom layout, then setting the version field (4 bits at position 48-51) to 1000 (8 in binary) and the variant field (2 bits at position 64-65) to 10. Example in pseudocode: custom_data[122 bits] | version[4 bits = 8] | variant[2 bits = 10]. Most languages provide byte manipulation functions to construct the final 128-bit value.

Use with caution. If your v8 design embeds sensitive information (customer IDs, internal structure, etc.), it may leak metadata. Document clearly what information is encoded and whether it's safe to expose publicly. For public APIs without custom requirements, use v4 (random, no metadata leakage).

Document the bit layout (what each field represents), generation algorithm, uniqueness guarantees, ordering behavior and any constraints or assumptions (clock synchronization, node IDs, etc.). Include examples and edge cases. Clear documentation is essential for maintainability, debugging, and cross-team collaboration when using v8.

Conclusion

GUID / UUID v8 is a powerful escape hatch for advanced use cases where predefined GUID / UUID versions don't fit. It provides maximum flexibility while maintaining RFC format compatibility, making it suitable for embedding custom sharding keys, hierarchical identifiers or domain-specific structures.

However, v8 should be used deliberately and sparingly. It requires careful design, comprehensive documentation and thorough testing to ensure uniqueness and avoid collisions. For most applications, v4 (random) or v7 (time-ordered, Unix milliseconds) remain better defaults.

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.