Where is the version stored in a UUID?

The version is the first hex digit of the third group — the 13th hex character overall, position 9 counting from 0 ignoring hyphens. A standard UUID looks like xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx, where M is the version digit and N encodes the variant.

What are the UUID versions?

Version 1 is time-and-MAC based, version 2 is DCE security, versions 3 and 5 are name-based (MD5 and SHA-1), version 4 is random, and version 7 is a newer time-ordered random UUID from RFC 9562. The tool names each one it detects.

What is the variant field?

The variant indicates the layout of the UUID. The most significant bits of the 17th hex digit determine it: 10x is the standard RFC 4122 variant, 0xx is the legacy NCS variant, and 110 is the Microsoft GUID variant.

Does it validate the format?

Yes. It checks that the input is 32 hexadecimal digits arranged in the 8-4-4-4-12 pattern. Invalid lengths or non-hex characters are rejected with an explanation before any version is reported.

What is the UUID Version Identifier?

Paste any UUID and instantly identify its version (1, 2, 3, 4, 5, or 7) and variant field per RFC 4122 and RFC 9562. Validates the format, reads the version nibble and variant bits, and explains what each means. Runs in your browser. It runs free in your browser on Gera Tools, with nothing uploaded.

UUID Version Identifier

Name: UUID Version Identifier
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Every RFC 4122 / RFC 9562 UUID carries its own version and variant inside its bits. This tool parses a UUID string, validates its shape, and tells you exactly which version generated it and which variant layout it uses.

How it works

A canonical UUID has 32 hex digits grouped 8-4-4-4-12:

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
              │      │
              │      └─ variant bits (top of this nibble)
              └─ version digit (1,2,3,4,5,7…)

The version is simply the value of the M nibble. The variant is read from the high bits of the N nibble: a leading 10 means the standard RFC 4122 variant, 0 means the legacy NCS variant, and 110 means the Microsoft GUID variant. The tool strips hyphens and braces, lower-cases the input, and confirms it is 32 hex digits before reading these fields.

Example and tips

f47ac10b-58cc-4372-a567-0e02b2c3d479 reports as version 4 (random), RFC 4122 variant, because the 13th digit is 4 and the 17th (a) starts with binary 10. A version 7 UUID like 018f... is time-ordered, making it sortable by creation time — increasingly preferred over version 4 for database keys.

UUID versions explained

Knowing the version of a UUID tells you a lot about how it was generated and what properties it has.

Version 1 — time and MAC address

Version 1 UUIDs embed a 60-bit timestamp (100-nanosecond intervals since October 15, 1582) and the MAC address of the generating machine. They are time-ordered within a single machine, but the embedded MAC address raised privacy concerns, so version 1 has largely been superseded. If you see a version 1 UUID in a legacy system, it may be possible to extract an approximate creation timestamp from it.

Version 2 — DCE Security

Rare in the wild. Version 2 replaces the lower timestamp bits with a POSIX UID or GID and a DCE domain. It was defined for Distributed Computing Environment RPC usage and is almost never generated by modern tooling.

Version 3 — name-based, MD5 hash

Version 3 generates a UUID deterministically from a namespace UUID and a name string using MD5. The same namespace + name always produces the same UUID, which makes version 3 useful for generating stable identifiers for known entities (for example, always producing the same UUID for a given URL). The MD5 basis means version 3 should not be used for new applications requiring cryptographic strength — version 5 is preferred.

Version 4 — random

The most widely used version. Version 4 takes 122 bits of random (or pseudo-random) data and sets the version and variant bits. The result is effectively unique with an astronomically low collision probability. Version 4 has no time component and no ordering — two version 4 UUIDs generated a millisecond apart are completely uncorrelated, which is a disadvantage for database indexing.

Version 5 — name-based, SHA-1 hash

Like version 3, but uses SHA-1 as the underlying hash. Preferred over version 3 for new deterministic UUID generation. The output is still truncated to 128 bits (SHA-1 produces 160 bits), so it is not a full-strength cryptographic hash — but it is better than MD5 for collision resistance.

Version 7 — time-ordered random (RFC 9562)

The newest practical version. Version 7 encodes a Unix millisecond timestamp in the most significant bits and fills the remaining bits with random data. The result is both random and sortable: UUIDs generated later sort after earlier ones. This makes version 7 an excellent choice for database primary keys, replacing sequential integers or version 4 UUIDs in systems that need monotonically increasing keys without a centralized counter.

Practical use cases for this tool

Debugging production logs — pasting a UUID from a log entry and immediately knowing it is version 4 (random) versus version 7 (time-ordered) can tell you which system or library generated it, narrowing the search space when debugging distributed systems.

Auditing third-party data — when receiving data exports or API responses, checking UUID versions helps identify whether identifiers are stable (version 3/5), random (version 4), or time-ordered (version 1/7). This affects how you can rely on ordering and idempotency.

Validating generated UUIDs — after updating a library or changing UUID generation logic, paste a sample output here to confirm the version changed as intended.

Understanding legacy GUIDs — Microsoft’s GUID format uses the same 8-4-4-4-12 structure but the variant field value differs (the N nibble starts with 110 in binary rather than 10). This tool detects and reports the Microsoft GUID variant so you know you are dealing with a GUID rather than an RFC 4122 UUID.