UUID Validator — Check Version and Format

How to use it#

Paste the UUID you want to check.
Read the version and variant, and the canonical form if you need to normalise it.
For version 1, 6 or 7, the creation time is shown as well.

How a UUID says which version it is#

The version is not metadata stored alongside the identifier. It is written into the value itself, in a single hexadecimal digit: the thirteenth, which is the first character of the third group. A UUID whose third group starts with a 4 is version 4, and one starting with 7 is version 7.

The next thing to look at is the first digit of the fourth group, which holds the variant. For anything produced in the last few decades it will be 8, 9, a or b, marking the RFC 4122 variant. Other values indicate the older Apollo NCS layout or a Microsoft GUID, both of which you are unlikely to meet outside legacy systems.

This is why a random-looking 32-digit hex string is not necessarily a UUID. It has the right shape, but unless those two positions carry sensible values it was not produced by anything following the specification, and a strict parser may reject it.

What a version 7 identifier gives away#

Version 7 puts the Unix timestamp in milliseconds into the leading 48 bits, which is what makes the values sort in creation order and what makes them behave well as database keys. It also means anyone holding one can read the moment it was created, down to the millisecond.

That is usually harmless and occasionally not. An identifier in a public URL that reveals exactly when an account was created, or lets someone compare two records and see which came first, is leaking something. Version 4 reveals nothing, which is the trade you are making when you choose between them.

Version 1 leaks more. Along with a timestamp it traditionally contains the network card address of the machine that generated it, which is why it fell out of favour for anything public.

Validating without a regular expression#

Most UUID validation in the wild is a regular expression copied from an answer somewhere, and most of those either accept the nil UUID when they should not, reject valid version 6 and 7 values because they were written before those existed, or ignore the variant digit entirely.

If you are writing the check yourself, decide first what you actually want. Confirming the string is 32 hex digits is a different question from confirming it follows RFC 4122, and confirming it came from a particular version is different again. A great many bugs come from a validator answering a stricter question than the caller intended.

Frequently asked questions#

What does the version number mean?

It says how the identifier was produced. Version 4 is random, version 7 is a timestamp plus randomness, versions 3 and 5 are hashes of a name, and version 1 is a timestamp plus a network card address. All are equally valid UUIDs; they differ in what they reveal and how they sort.

Is the nil UUID valid?

Yes, though it is a special case. The all-zeroes value is reserved by the specification to mean the absence of an identifier, and it carries no version or variant. Many validators reject it, which is often what you want if it turned up where a real identifier was expected.

Does capitalisation matter?

No. UUIDs are compared case-insensitively by specification, so the uppercase and lowercase forms are the same value. The canonical form is lowercase with hyphens, and normalising to it before storing saves you from ever having to think about this again.

Why does my UUID not show a creation time?

Only versions 1, 6 and 7 contain one. Version 4 is entirely random apart from the version and variant bits, and versions 3 and 5 are hashes, so none of them has a timestamp to read.

Can I check that a UUID is genuine?

Only that it is well formed. Nothing about a UUID proves where it came from, because anyone can construct a value with the right shape. If an identifier needs to be trusted, it has to be checked against whatever issued it.