f47ac10b-58cc-4372-a567-0e02b2c3d479Duplicate of line 1
Valid
v4
RFC 4122
8
886313e1-3b8a-5372-9b90-0c9aee199e5d
Valid
v5
RFC 4122
9
f47ac10b-58cc-4372-a567-0e02b2c3d479Duplicate of line 1
Valid
v4
RFC 4122
10
f47ac10b-58cc-4372-a567-0e02b2c3d47A UUID has 32 hexadecimal digits; this has 31. 1 more needed.
Invalid
—
—
11
f47ac10b-58cc-4372-a567-0e02b2c3d47z"z" is not valid here — a UUID contains only the digits 0-9 and the letters a-f
Invalid
—
—
12
not-a-uuid-at-all"not" is not valid here — a UUID contains only the digits 0-9 and the letters a-f
Invalid
—
—
13
6fa459ea-ee8a-3ca4-894e-db77e160355e
Valid
v3
RFC 4122
14
c232ab00-9414-11ec-b3c8-9f6bdeced846
Valid
v1
RFC 4122
14 checked · 11 valid · 3 invalid · 9 unique
Validated in your browser — nothing is uploaded.
Everything happens locally in your browser. Nothing is uploaded or stored.
What is UUID validation?
Checking that a value really is a universally unique identifier — the right length, the right characters, the hyphens in the right places — and then reading what it says about itself: which version produced it, and which layout it follows.
The canonical form, and what each part means
1f47ac10b-58cc-4372-a567-0e02b2c3d4792 ^ ^3 | └── variant: the layout family4 └────── version: how it was generated568 hex - 4 - 4 - 4 - 12 hex = 32 digits, 36 characters
The distinction worth holding on to is that valid does not mean real. A well-formed UUID tells you the value could have come from a generator; it says nothing about whether it identifies anything, or whether whoever sent it should have access to it. Validation is a format check and a first gate, not an authorisation.
How UUID validation works
1. Strip the decoration. Braces from Windows, a urn:uuid: prefix, quotes from a CSV — none of these are part of the value, and all are common.
2. Count the hex digits. There must be exactly 32, drawn only from 0–9 and a–f. Case does not matter.
3. Check the hyphens. Canonical form breaks them 8-4-4-4-12. A value with none is still readable, but it is not canonical.
4. Read the variant. The top bits of the 17th digit say which layout the value follows. This has to be read before the version, because in a non-RFC variant the version digit means nothing.
5. Read the version.The 13th digit, 1 to 8. That tells you how the value was generated — and, for v1, v6 and v7, when. A v7’s leading 48 bits are Unix milliseconds, which a timestamp converter will read back as a date.
All of it happens in your browser. The identifiers people check are database keys and customer records, so nothing is uploaded.
UUID versions explained
Version 1 — time based
A timestamp plus the machine's MAC address. Sortable by creation time, but it leaks which machine made it and roughly when, which is why it fell out of favour.
Version 3 — name based (MD5)
Derived by hashing a namespace and a name with MD5. The same inputs always give the same UUID, which is its whole point — and MD5 is why v5 exists.
Version 4 — random
122 random bits. The one almost everyone means by "UUID". Collisions are not worth worrying about; the numbers involved are absurd.
Version 5 — name based (SHA-1)
Like v3 but with SHA-1. Use this rather than v3 when you need the same name to always produce the same identifier.
Version 6 — time ordered
v1 with the timestamp rearranged so the value sorts chronologically as text. Added by RFC 9562 for databases that index identifiers.
Version 7 — Unix time ordered
A 48-bit Unix millisecond timestamp followed by random bits. The modern choice for database keys: sortable, index-friendly, and it leaks nothing but the time.
Version 8 — custom
Reserved for implementation-specific formats. The layout is whatever its creator decided, so nothing can be inferred beyond the version and variant.
Version 2 exists as well — DCE security — but nothing generates them in practice, so a v2 value in your data is far more likely to be a corrupted v1 than a genuine one.
If you are choosing: v4 for general identifiers, and v7 for anything that becomes a database key, because its time-ordered prefix keeps an index from fragmenting the way random values do. The UUID generator produces either in bulk.
UUID variants explained
The variant is encoded in the top bits of the 17th hex digit, and it says which specification the rest of the value follows.
RFC (variant 1)bits 10x
The modern standard, defined by RFC 4122 and now RFC 9562. Effectively everything you will encounter. The version digit only means something in this variant.
NCS (variant 0)bits 0xx
The Apollo Network Computing System layout, which predates the RFC. Legacy, and vanishingly rare — but a value in this range is still a well-formed UUID.
Microsoft (variant 2)bits 110
The old Microsoft GUID layout, which stored some fields in a different byte order. Occasionally turns up in data exported from older Windows systems.
Reserved (variant 3)bits 111
Reserved for future definition. Nothing legitimately produces these, so one appearing in your data usually means the value was corrupted or invented.
Common UUID validation errors
Wrong length
A UUID is exactly 32 hexadecimal digits. Too few usually means truncation by a column that was too narrow; too many usually means two values ran together.
Invalid characters
Only 0–9 and a–f are allowed. The classic is a capital O where a zero belongs, which happens whenever a value has been read aloud or retyped from a screenshot.
Incorrect hyphens
The canonical form breaks 8-4-4-4-12. Hyphens elsewhere, or a missing one, is usually a sign the value was reassembled by hand or by a bad regular expression.
Invalid version
The digit at position 13 must be 1 to 8. A zero there means the value was fabricated or is not really a UUID — random hex is not a UUID.
Invalid variant
The top bits of position 17 must mark a known variant. A value in the reserved range is well-formed hex but not a UUID any specification defines.
Empty value
Easily missed in a batch: a blank cell in a CSV column reads as a missing identifier rather than an invalid one, and is worth catching before it reaches a query.
UUID validation best practices
Accept generously, store canonically. Take braces, uppercase and missing hyphens on the way in — people paste from all sorts of places — but normalise to lowercase hyphenated form before storing, so two spellings of one identifier never become two rows.
Store as a native UUID type where you can. Postgres has one, and it is 16 bytes against 36 for text, with a faster index. Where you must use a string, make it a fixed-length column so truncation is impossible.
Validate at the API boundary. Checking the format before the value reaches a query turns a driver error into a clear 400 Bad Request, and stops malformed input travelling deeper into the system.
Do not treat validity as authorisation. A well-formed UUID is still just a number someone sent you. Check that the caller may see that record — unguessability is not a permission model.
Watch for the nil UUID in real data. All zeros is valid and meaningful, but in practice it usually means a variable was never set. Counting them separately is how you notice.
Check the version if it matters. If your system relies on time-ordered keys, a v4 value slipping into a v7 column will not error — it will just quietly fragment the index.
Deduplicate by canonical form, not by string. Otherwise the same identifier in two different cases passes a uniqueness check it should fail.
Common use cases
Database IDs
Check a column of primary keys before a migration, and find the duplicates and blanks that would break a unique constraint.
API requests
Validate an identifier at the boundary so a malformed value fails with a clear message rather than a driver's type error.
Microservices
Correlation ids travel between services. Checking a batch from a log tells you quickly whether one hop is mangling them.
Authentication systems
Session and token identifiers are often UUIDs. Confirming the version tells you whether they are random or time-ordered — and therefore guessable or not.
Distributed applications
When several nodes generate ids independently, a duplicate check across a merged list is the fastest way to confirm they really are independent.
Event tracking
Analytics pipelines drop malformed event ids silently. Validating an export shows how many were lost and why.
Frequently asked questions
Is this UUID Validator free?
Yes. Single and batch validation, the result table, filtering, search and all three export formats are free, with no account and no limit on how many UUIDs you check.
Is my UUID uploaded?
No. Every value is validated by JavaScript running in your browser. Nothing is sent to a server, nothing is stored and nothing is logged. You can disconnect from the network after the page loads and it keeps working — which matters when the identifiers are customer records or internal database keys.
Can I validate multiple UUIDs?
Yes, and that is what this tool is for. Paste a list, one per line or separated by commas, semicolons or tabs, and every value is checked at once. Up to 100,000 values are read, and the table only renders the rows currently on screen, so a large list stays responsive.
Which UUID versions are supported?
All of them. Versions 1 through 8 are recognised and named, including the newer v6 and v7 from RFC 9562, and the reserved v8. The nil UUID (all zeros) and the max UUID (all f's) are recognised as the special values they are rather than reported as odd version numbers.
What is RFC 4122?
The specification that defined the UUID format in 2005 — the eight-four-four-four-twelve hex layout everyone recognises, along with the version and variant fields. It was replaced by RFC 9562 in 2024, which kept everything compatible and added versions 6, 7 and 8. When a tool says a UUID is "RFC 4122 compliant" it usually means the variant bits mark it as belonging to that family rather than to the legacy Microsoft or NCS layouts.
Can I validate UUID v7?
Yes. v7 is the time-ordered version added by RFC 9562, and it is recognised alongside every other version. Because its first 48 bits are a Unix timestamp in milliseconds, a v7 value also carries a readable creation time.
Why is my UUID invalid?
The usual causes are the wrong number of hex digits, a character outside 0–9 and a–f (an O instead of a 0 is the classic), or hyphens in the wrong places. The table names the specific problem for each value rather than just marking it red, and says how many characters are missing or extra.
Does formatting matter?
Not to this tool. Uppercase, lowercase, braces around the value as Windows writes them, a urn:uuid: prefix, or no hyphens at all — all are accepted and normalised to the canonical lowercase hyphenated form. That form is what the reports contain, and what you should store.
How are duplicates detected?
By canonical form, so the same UUID written in different cases or with different punctuation counts as one value rather than several. Each repeat is flagged with the line its first occurrence appeared on, and the summary reports how many distinct values the list actually holds.
What are UUID variants?
The variant field says which layout the rest of the UUID follows. Almost everything you will meet is the RFC variant. NCS is a legacy Apollo format, Microsoft is the old GUID layout, and one range is reserved for future use. A value in one of the legacy variants is still a well-formed UUID — it simply is not the modern kind, and the version digit means nothing in it.
Can I export validation results?
Three ways. A plain text file of the valid values in canonical form, ready to paste back into a query. A CSV with every row's status, version, variant and problem, for a spreadsheet. And a JSON report with the summary and every result as structured data, for feeding into another program.
Can I upload a file?
Yes. Use the upload button or drag a .txt or .csv file onto the page. Files up to 10 MB are read locally with the browser's FileReader. Because a UUID never contains a comma, semicolon or tab, a CSV column of identifiers is extracted correctly without needing to say which column it is in.
Is the nil UUID valid?
Yes. All zeros is a well-formed UUID with a specific defined meaning — the absence of a value. It is worth knowing when one appears in your data, though, because it often means a variable was never set rather than that someone deliberately chose it. The tool counts nil and max values separately for that reason.
Should I validate UUIDs in my application?
Yes, at the boundary. Checking the format before a value reaches a database query catches malformed input early and gives a clearer error than a driver's type failure. It is not a security control on its own — a well-formed UUID can still be one the caller has no right to — but it is a cheap first gate.
Are there keyboard shortcuts?
Ctrl/Cmd+Enter validates immediately, Ctrl/Cmd+Shift+C copies the valid UUIDs, Ctrl/Cmd+Shift+D downloads the JSON report, Ctrl/Cmd+Shift+L loads another sample list and Ctrl/Cmd+Shift+Delete clears the input. Ctrl/Cmd+F opens the search, and Escape closes it.
Keep going
Tools that pair with this one
Same privacy model — everything below runs in your browser too.
