search

Found

info Overview

Paste a UUID to detect its version (v1-v8, Nil, Max) and variant (RFC 4122 etc.), with the version nibble colour-coded and v1, v6, v7 timestamps decoded.

📘 How to Use

  1. Paste a UUID string into the input field
  2. Check the colour-highlighted version nibble and variant bits in the hex byte view
  3. Read off the version, variant, and any extracted timestamp or node

UUID Version Detector

Accepts hyphenated, brace-wrapped, or urn:uuid: prefixed forms.

Hex byte view

Version nibble Variant bits

Version

v4

Variant

RFC 4122

Overview

Extracted metadata

—
—

grid_view Related

Article

UUID Version Detector | Decode v1–v8, Nil and Max in Seconds

Paste a UUID and identify every version from v1 through v8, plus Nil, Max and invalid input. The 13th hex digit (version nibble) and 17th digit (variant bits) are colour-coded in the byte view, and embedded timestamps from v1, v6 and v7 are decoded along with the clock sequence and node MAC for v1 and v6.

💡 About this tool

If you have ever stared at a column of UUIDs in a log file and wondered "is this one time-based or pure random?", you know the problem. You can eyeball that the 13th character is the version, but figuring out the variant from the 17th digit, or back-calculating a v1 60-bit timestamp from the 1582 Gregorian epoch by hand, is not realistic.

This tool normalises whatever you paste into a 32-hex-digit string and classifies it against both RFC 4122 (v1–v5) and RFC 9562 (v6, v7, v8, Nil, Max). It accepts hyphenated, brace-wrapped and urn:uuid: prefixed forms, so you can drop in a string copied straight out of code or a database row. The version nibble and variant bits are highlighted in the byte view, which doubles as a way to actually see the UUID's bit layout instead of trusting a library.

🧐 Frequently Asked Questions

Which digit determines the version? After stripping hyphens you have 32 hex digits; the 13th one (the first character of the third group) is the version nibble. A value of 4 means random, 1 means time-based, 7 means a Unix-time ordered UUID, and so on.

What is the difference between version and variant? The version tells you the generation method (time, random, name-hash). The variant tells you the bit-layout family. The tool reads the high bits of the 17th digit to report RFC 4122, NCS, Microsoft or Reserved. Almost every UUID you meet in the wild is the RFC 4122 variant.

Why does my v1 UUID show a strange year? v1 and v6 timestamps count 100-nanosecond intervals from 15 October 1582, the date the Gregorian calendar was adopted, not from the Unix epoch. The tool applies the correct offset and renders the result as an ISO 8601 string. v7, by contrast, is plain Unix milliseconds.

Can it tell a v4 from a v7 at a glance? Yes. Both are common today, but v7 carries a real timestamp in its first 48 bits while v4 is 122 bits of randomness. The tool labels each and, for v7, decodes the creation time so you can confirm sort order.

What happens with an all-zero UUID? It is reported as the Nil UUID. An all-ones UUID is reported as Max. Both are reserved special values defined in RFC 9562, typically used as placeholders or unset markers.

📚 Why v7 Is Quietly Taking Over

A lot of teams that used v4 everywhere are now switching primary keys to v7, and the reason is database index behaviour. A v4 value is fully random, so inserting it scatters rows across a B-tree and fragments the index over time. A v7 value starts with 48 bits of millisecond timestamp, so newly generated keys land in roughly ascending order and stay tightly packed. v6 exists for a related reason: it reshuffles the v1 timestamp fields so the bytes sort lexically, giving teams with existing v1 data a sortable migration target. The whole performance story turns on a single hex digit, which is exactly the digit this tool highlights.