UUID Version Detector

How to Use the UUID Version Detector

1. Paste a UUID into the input box. You can paste the canonical 8-4-4-4-12 hyphenated form (550e8400-e29b-41d4-a716-446655440000), the bare 32-hex form, or a Microsoft-style value wrapped in curly braces. Case is ignored.
2. Read the detected version. The detector pulls the 13th hexadecimal character (the first character of the third group, right after the second hyphen) and reports it as v1, v3, v4, v5, v6, v7, or v8 with a short description of the algorithm.
3. Inspect the variant. The high bits of the 17th hex character (first character of the fourth group) tell you which UUID specification family the value belongs to. Modern UUIDs are variant 10xx (RFC 4122 / RFC 9562); the detector flags the legacy NCS, Microsoft GUID, and future-reserved variants explicitly when it sees them.
4. Use the embedded timestamp. For v1, v6 and v7 the detector decodes the embedded creation timestamp and shows it in ISO 8601 form. You can paste that into a log search to find the originating event.
5. Copy the report with a single click. The clipboard receives a plain-text summary you can paste into a Slack thread, a bug report, or a code review comment.

What Each UUID Version Means

UUIDs look identical at a glance but encode very different generation strategies, and treating them all the same is the source of an entire class of subtle bugs. Version 1 packs a 60-bit timestamp and a 48-bit MAC address (or random pseudo-MAC) into the value; it is good for ordering and very bad for privacy. Version 3 hashes a namespace UUID and a name with MD5 to produce a deterministic identifier - same inputs, same UUID, no coordination needed. Version 4 is purely random with 122 bits of entropy from the OS cryptographic RNG and is the default for almost everything that does not need ordering or determinism. Version 5 is identical in shape to v3 but uses SHA-1 instead of MD5 and is recommended over v3 for new code. Version 6, introduced by RFC 9562 in May 2024, reorders v1's timestamp bytes so that lexicographic sort order matches generation order - the same data as v1, just rearranged to be database-friendly. Version 7 is the rising star: 48 bits of Unix milliseconds followed by 74 bits of randomness, producing globally unique identifiers that also sort by creation time in any database B-tree without index fragmentation. Version 8 is a custom version that lets applications define their own internal layout while still claiming the RFC 9562 variant bits.

Why You Need to Detect the Version

Several real situations demand version awareness. Migrating a primary key column from v4 to v7 means re-sorting historical data; the detector confirms which rows already use v7 and which still use the old random format. Debugging an authorization vulnerability means proving that an access token is unguessable; v1 and v6 leak both the creation time and the generating host, so finding either in a token bag is a finding worth reporting. Reading a Windows-era database means recognising Microsoft-variant GUIDs and rendering them with the correct byte order on output. Tracing a request across services means turning the timestamp inside a v1 or v7 correlation ID back into a wall-clock time and using it to filter logs to a tight window. The detector handles each of these in seconds without you having to open a Python REPL or remember which hex digit holds the version.

Common Pitfalls When Working With UUIDs

• Assuming UUID v4 is the only kind. A v1 UUID that leaks a MAC address looks identical at first glance to a v4 UUID. Use the version nibble, not the string length, to identify it.
• Treating UUIDs as bearer tokens. v4 has 122 bits of randomness which is enough to be unguessable; v1 and v6 give an attacker the creation timestamp; v7 reveals creation milliseconds. Never use a UUID as the only proof of authorization for a high-value operation.
• Sorting v4 in the database. v4 is random and B-tree inserts cause write amplification. If you need both global uniqueness and index locality, switch to v7 - the detector confirms what you have.
• Reading Microsoft GUID byte order as RFC 4122. Microsoft stores the first three fields little-endian, RFC stores them big-endian. Same logical UUID, different byte sequence in raw storage. The string form is identical, so the detector reports the variant but cannot tell you which endianness the bytes were in.
• Ignoring the nil and max UUIDs. Both are sentinels, not actual identifiers, and inserting either into a "real" UUID column is a common source of off-by-one bugs. The detector flags them with a note.

Privacy and Security Notes

v1 UUIDs in particular have historical baggage. They were originally specified to include the MAC address of the generating machine, which leaks identifying information across requests. Modern v1 implementations typically substitute a random pseudo-MAC, but you cannot tell that from the UUID alone - if you see v1 in user-facing data you should treat it as potentially containing host information. v6 inherits the same shape, but because it is new, implementations tend to use a random node ID by default. v3 and v5 are deterministic, so anyone with the same namespace + name input can regenerate the UUID - never use them for unguessable tokens. v4 and v7 are the safe defaults for tokens; v4 when you do not need ordering, v7 when you do. The detector cannot enforce any of this for you, but reading the version on every untrusted UUID is the first step to noticing the problem.

How the Detection Logic Works

Everything happens in your browser. The detector trims whitespace, removes any leading or trailing braces or parentheses, lowercases the string, and validates against the canonical regular expression (or against the 32-hex hyphenless form, normalising back to canonical for display). It then reads the version nibble by indexing into the hex characters and reads the variant byte by parsing the first two hex characters of the fourth group. For v1 and v6 it reconstructs the 60-bit timestamp using BigInt arithmetic and subtracts the Gregorian-to-Unix offset of 122192928000000000 hundred-nanosecond units. For v7 it reads the leading 48-bit value as Unix milliseconds and renders it directly. No data is sent over the network, no analytics ping is triggered by the parse, and the page itself loads no third-party scripts on the parse path. If you want to verify, disconnect your network after the page loads and keep using it - the detector keeps working.

When to Pair the Detector With Other Tools

UUID parsing rarely happens in isolation. After you identify a v7 UUID and read its timestamp, the Unix Timestamp Converter helps you turn it into a human-readable wall-clock time across time zones. The UUID Generator is the inverse tool - mint fresh v4 values for tests and fixtures. The JSON Formatter pairs naturally when you are extracting a UUID from a larger payload and want to pretty-print the surrounding object. The Regex Tester is useful if you want to write your own UUID-extracting expression for log scraping. Together they cover the standard "see a UUID, understand it, look up related context" workflow that comes up in incident response and forensic analysis.