An empty GUID (also called a nil UUID) is a special, standardized GUID / UUID value where all 128 bits are set to zero. It serves as a sentinel value representing "no identifier", "uninitialized" or "null reference" in systems that use GUIDs / UUIDs.
Special Value (Not a Version): The nil UUID (or empty GUID) is not a versioned GUID / UUID. It's a reserved constant defined by the specification to represent the absence of a value, similar to NULL in databases or null pointers in programming.
Status and standardization
The nil UUID (or empty GUID) has been part of the GUID / UUID specification since RFC 4122 (July 2005) and continues to be defined in RFC 9562 (May 2024).
The nil UUID (or empty GUID) is universally recognized and safe to use as a placeholder or default value. It is the only GUID / UUID value that is intentionally not unique. All nil UUIDs (or empty GUIDs) are identical by definition.
Common use cases
Default / uninitialized value: used to represent an unset or missing GUID / UUID field before a proper identifier is assigned.
Null reference substitute: serves as an alternative to NULL in contexts where a valid GUID / UUID structure is required (e.g., non-nullable database columns, APIs with strict schemas).
Placeholder in data structures: used in configurations, templates or data structures to indicate "no associated entity" or "not applicable."
Sentinel value in algorithms: marks boundary conditions, empty lists or termination conditions in GUID / UUID-based data structures.
Testing and debugging: provides a recognizable constant for testing GUID / UUID handling logic without generating real identifiers.
Explicit "none" signal: communicates intent more clearly than omitting the field entirely, especially in JSON or XML where the field must be present.
Important considerations
Not unique: the nil UUID (or empty GUID) is the same everywhere. Never use it as an actual identifier for entities, records or objects that need to be distinguished.
No version or variant fields: since all bits are zero, there's no version or variant information. It doesn't belong to any GUID / UUID version (v1-v8).
Database constraints: if your database enforces uniqueness constraints on GUID / UUID columns, allowing nil UUIDs (or empty GUID) may cause issues when multiple rows have the same nil value.
Application logic: ensure your application logic explicitly checks for the nil UUID (or empty GUID) when using it as a sentinel, to avoid treating it as a valid entity identifier.
API design: document whether your API accepts nil UUIDs (or empty GUID) and what behavior they trigger (e.g., "return all," "skip," or "error").
Technical details
Bit layout: the nil UUID is 128 bits, all set to zero. In the canonical 36-character string format (8-4-4-4-12), it is represented as:
Version and variant: the nil UUID (or empty GUID) has no version or variant fields. The first hex digit of the third group is 0 (not a valid version number), and the first hex digit of the fourth group is also 0 (not a valid variant).
Field structure (all zeros)
Field Name Bits Hex Digits Value
─────────────────────────────────────────────────────────────────────────
time_low 32 8 0x00000000
time_mid 16 4 0x0000
time_hi_and_version 16 4 0x0000
clock_seq_and_variant 16 4 0x0000
node 48 12 0x000000000000
All field names above are borrowed from the standard GUID / UUID structure for documentation purposes, but they have no semantic meaning in the nil UUID (or empty GUID), every bit is simply zero.
Try our GUID / UUID Inspector to verify that a UUID (or GUID) is the nil UUID (or empty GUID) (all zeros).
Format and recognition
The nil UUID (or empty GUID) is easy to recognize: it's the only GUID / UUID where all hex digits are zero.
Most GUID / UUID libraries provide constants or helper functions for the nil UUID (or empty GUID), such as Guid.Empty in .NET, uuid.Nil in Go's google/uuid package, or checking uuid == uuid.UUID(int=0) in Python.
Frequently Asked Questions
The nil UUID (or empty GUID) 00000000-0000-0000-0000-000000000000 is a standardized sentinel value representing "no identifier" or "uninitialized." Use it as a default value for GUID / UUID fields, a null reference substitute in non-nullable contexts or a placeholder in data structures. Never use it as an actual identifier for entities or records that need to be distinguished.
No, the nil UUID (or empty GUID) is intentionally not unique. All nil UUIDs (or empty GUIDs) are identical by definition (all 128 bits are zero). This is the opposite of regular GUIDs / UUIDs like v4 or v7, which are designed to be globally unique.
Yes, but with caution. If your database column has a unique constraint, multiple rows with nil UUIDs (or empty GUIDs) will violate uniqueness. Use the nil UUID (or empty GUID) only in scenarios where: (1) the column allows it explicitly, (2) you use it sparingly (e.g., a single default row) or (3) uniqueness is enforced by other means. For nullable GUID / UUID columns, consider using NULL instead of the nil UUID (or empty GUID) to avoid ambiguity.
NULL indicates "no value exists" at the database/language level. Nil UUID (or empty GUID) is an actual GUID / UUID value (all zeros) that means "no identifier." Use NULL when the field is truly absent; use nil UUID (or empty GUID) when you need a valid GUID / UUID structure for non-nullable fields, APIs with strict schemas or when you want to explicitly signal "uninitialized" in serialized data (JSON, XML).
No. Since all bits are zero, there's no version or variant information. The nil UUID (or empty GUID) doesn't belong to any UUID version (v1-v8). It's a special reserved value defined by the specification, not a generated UUID.
Java: Check against a predefined NIL_UUID = new UUID(0L, 0L)
Always use the standardized nil UUID (or empty GUID) (all zeros). Custom sentinel values like 99999999-9999-9999-9999-999999999999 or ffffffff-ffff-ffff-ffff-ffffffffffff are not standardized and can cause confusion, interoperability issues or unintentional collisions with real GUIDs / UUIDs. The nil UUID (or empty GUID) is universally recognized and documented in RFC 4122 and RFC 9562.
Extremely unlikely for random GUIDs / UUIDs. For v4 (random), the probability of generating all zeros is approximately 1 in 2¹²⁸ (less than 1 in 10³⁸). For time-based GUIDs / UUIDs like v7, it's impossible because the timestamp and version/variant fields prevent all-zero values. Generators should explicitly avoid producing nil UUIDs (or empty GUIDs) if encountered.
Yes, but document its meaning clearly. In REST APIs, the nil UUID (or empty GUID) can represent "no associated resource", "default value" or "uninitialized." In JSON/XML serialization, it ensures the field is present (avoiding null ambiguity in strict schemas). Make sure client and server agree on the semantic meaning—does it mean "fetch all", "return error" or "use default"?
RFC 9562 defines a Max GUID / UUID (ffffffff-ffff-ffff-ffff-ffffffffffff, all bits set to 1) as another reserved value, though it's less commonly used than nil (empty). Some applications also define custom sentinel GUIDs / UUIDs for specific purposes, but only nil (empty) and max are standardized. For most applications, the nil UUID (or empty GUID) is sufficient as a sentinel value.
Conclusion
The nil UUID (or empty GUID) is a universally recognized sentinel value that serves as the GUID / UUID equivalent of NULL or zero. It's safe to use as a default value, placeholder or "no identifier" signal in applications, databases and APIs (avoid in logs).
Remember that the nil UUID (or empty GUID) is intentionally not unique and should never be used as an actual identifier for entities or records. For generating proper identifiers, use v4 (random), v7 (time-ordered), or other versioned GUID / UUID formats depending on your requirements.
Learn more
These articles expand on related concepts, formats and practical considerations.