UUID Validator & Inspector

Q: What does the version digit actually tell me?

It says how the identifier was produced, which determines what you can rely on. Version 4 is random, so it carries no information beyond being unique. Version 1 is timestamp plus MAC address, so it leaks when and where it was created and sorts roughly by time. Version 7 is timestamp plus randomness — deliberately designed to sort by creation time without leaking hardware. Versions 3 and 5 are hashes of a name within a namespace, so the same input always produces the same UUID. The digit sits at position 13, the first character of the third group.

Q: Why does a UUID I know is valid get rejected?

Usually the variant bits rather than the format. A well-formed UUID has to have the correct variant marker at position 17 — the first character of the fourth group must be 8, 9, a or b for the standard RFC variant. A string can look perfectly UUID-shaped, with the right hyphens and 32 hex digits, and still not be a conforming UUID because that nibble is wrong. That usually means it was assembled by hand or generated by something taking shortcuts, and the tool tells you exactly which rule failed.

Q: Can I recover a creation time from a UUID?

From versions 1, 6 and 7, yes, and this tool extracts it. Version 1 encodes 100-nanosecond intervals since 1582 — the Gregorian calendar reform — which is why the raw value looks so strange. Version 7 encodes ordinary Unix milliseconds, which is one reason it is easier to work with. Version 4 contains no timestamp whatsoever, so any tool claiming to date a v4 UUID is fabricating it. That difference matters if you are relying on identifiers to be sortable.

Q: Are the nil and max UUIDs valid?

They are valid special values, but they are not version 4 or any other version — they are defined separately by the specification. The nil UUID is all zeros and means the absence of a value. The max UUID is all fs and was formally defined more recently as the opposite sentinel. Both are legitimate to store and pass around, but seeing one in production data where a real identifier was expected almost always indicates an uninitialised field rather than a deliberate choice, so the tool calls them out.

Q: Does formatting matter — braces, uppercase, no hyphens?

Not to the underlying value. The canonical form is 36 lowercase characters with four hyphens, but Microsoft tooling commonly wraps GUIDs in braces, some systems store them uppercase, and databases frequently strip the hyphens to save space. All of those represent the same 128 bits. This tool accepts every variation and shows you the canonical form alongside the compact and braced ones, so you can match whatever the receiving system expects.

Q: Should I be worried about a version 1 UUID in public data?

It is worth knowing about. A v1 UUID embeds the generating machine's MAC address and a precise timestamp, so publishing one discloses a stable hardware identifier and exactly when the record was created. That has been used in real investigations to link documents to specific computers. For anything user-facing prefer version 4 for pure randomness, or version 7 if you want time ordering without the hardware disclosure.

Check whether a UUID is well formed and see what it contains — version, variant, and the creation timestamp where one is embedded.

UUID or GUID

Validation and inspection happen entirely in your browser. Nothing you paste is uploaded.

What It Does

Paste a UUID and this tells you whether it is genuinely well formed and, more usefully, what is inside it. A UUID is not an opaque blob — 128 bits with structure. Four bits identify the version, which is to say how the identifier was generated, and two or three more identify the variant. Depending on the version, the rest may contain a precise creation timestamp, a hardware address, a hash of some name, or nothing but randomness. Knowing which you have determines what you can rely on: whether the value sorts meaningfully by time, whether it reveals anything about the machine that made it, and whether the same input would produce it again. Validation catches the near-misses too, where a string is UUID-shaped but has the wrong variant bits.

When to Use It

A record arrived with an identifier that is being rejected downstream and you need to know whether the value or the receiving system is at fault.
You are auditing data for privacy and want to find version 1 UUIDs, which disclose a MAC address and a creation time.
An identifier needs converting between the braced GUID form your legacy system uses and the canonical form your API expects.
You want to confirm that your generator is producing the version you configured rather than defaulting to something else.
A migration produced suspicious identifiers and you want to spot nil UUIDs sitting where real ones should be.

Worked Examples

018f4b1c-8a2e-7c3d-9f1a-2b3c4d5e6f70

A version 7 UUID. The leading digits are a Unix millisecond timestamp, so the tool can report exactly when it was created — and these sort chronologically as plain strings, which is the whole point of v7.

00000000-0000-0000-0000-000000000000

The nil UUID. Structurally valid and defined by the specification, but finding one in a column that should hold real identifiers almost always means a field was never populated.

{6BA7B810-9DAD-11D1-80B4-00C04FD430C8}

A braced uppercase GUID, the form Windows tooling emits. Accepted and normalised — and being version 1, the tool extracts both its 1998 timestamp and the MAC address baked into it.

Features

Validation against the full RFC rules including variant bits

Version detection from 1 to 8

Embedded timestamp extraction for versions 1

6 and 7

MAC address extraction from version 1 identifiers

Nil and max UUID recognition

Accepts braces

uppercase and hyphen-free input

Canonical

compact

braced and URN forms shown

Clear explanation of which rule failed when invalid

Notes on what each version is suitable for

Runs entirely in your browser

How to Use

1. Paste a UUID in any common format — canonical, braced, uppercase or without hyphens. 2. The verdict appears immediately, with the reason if it is not valid. 3. Read the breakdown for version, variant and any embedded timestamp. 4. Copy whichever alternative format the receiving system expects. 5. Clear to check another.

Common Mistakes

Validating with a regex that only checks the shape. Thirty-two hex digits and four hyphens is not enough — the variant nibble has to be 8, 9, a or b, and a shape-only check passes strings that are not conforming UUIDs.
Assuming version 4 identifiers sort by creation time. They are random, so ordering by them scatters rows arbitrarily. Use version 7 if you want identifiers that sort chronologically.
Publishing version 1 UUIDs in user-facing data. They embed the generating machine's MAC address and a precise timestamp, which is more disclosure than most people intend.
Treating a nil UUID as a valid identifier. It is structurally legal but semantically means nothing is set, so it usually signals a bug upstream rather than real data.
Storing UUIDs as 36-character strings without thinking. The value is 128 bits; a native UUID column or a 16-byte binary field is less than half the storage and indexes far better.

Frequently Asked Questions

What does the version digit actually tell me?

Why does a UUID I know is valid get rejected?

Can I recover a creation time from a UUID?

Are the nil and max UUIDs valid?

Does formatting matter — braces, uppercase, no hyphens?

Should I be worried about a version 1 UUID in public data?