Validate UUID format and identify version (v1, v3, v4, v5) in the browser. Checks RFC 4122 compliance: structure, variant bits, version field, and hyphen placement.
Use this free online UUID Validator directly in your browser. No signup required, no data leaves your device. Part of Utilier — a collection of 133+ developer utilities.
What is UUID Validator?
A UUID (Universally Unique Identifier) is a 128-bit value typically displayed as 36 characters with hyphens: 8-4-4-4-12 hex digits. This tool validates the format, checks variant and version fields, and identifies the UUID type — time-based (v1), name-based MD5 (v3), random (v4), or name-based SHA-1 (v5).
Format validation: Checks that the input is exactly 36 characters with hyphens at positions 8, 13, 18, and 23, and that all non-hyphen characters are valid hexadecimal (0-9, a-f).
Version detection: The version is encoded in the 13th hex digit (first character of the third group). 1 = time-based, 3 = MD5 hash, 4 = random, 5 = SHA-1 hash.
Variant checking: The variant bits (first two bits of the 17th hex digit) indicate the UUID layout. RFC 4122 UUIDs have variant 10x in binary, which corresponds to hex 8, 9, a, or b.
Case insensitive: UUIDs are typically lowercase, but uppercase and mixed-case UUIDs are equally valid per RFC 4122. The validator accepts all forms.
Nil UUID detection: The all-zeros UUID (00000000-0000-0000-0000-000000000000) is valid and called the nil UUID. It is used as a placeholder or default value.
Why use UUID validator?
APIs, databases, and distributed systems rely on UUIDs for unique identifiers. A malformed UUID breaks queries, lookups, and foreign key references — and the error is often silent. Validating the format and version ensures your IDs are correct before they cause runtime failures.
Catch typos before runtime: A missing hyphen, transposed digits, or non-hex character makes a UUID invalid. Validating before inserting into a database or sending to an API prevents cryptic errors hours later.
Identify UUID version mismatches: If your system expects v4 (random) but receives v1 (time-based with MAC address), that is a privacy or compatibility issue. The validator shows the version immediately.
Debug API responses: When an API returns an ID field and lookups fail, paste it into the validator to confirm it is a well-formed UUID and not a different ID format (ULID, nanoid, integer).
Verify UUID generation code: If you implemented a custom UUID generator or are using a new library, validate a few outputs to ensure they conform to RFC 4122.
Runs locally: No upload — UUIDs are validated entirely in the browser. Safe for production IDs, user records, or any sensitive identifiers.
When to use UUID validator
Use whenever you need to verify that a string is a valid UUID or determine its version.
Debugging why a database query with a UUID foreign key returns no results — the UUID may be malformed.
Validating user input in forms or APIs that accept UUIDs before passing them to backend services.
Identifying which UUID version a system or library is generating (v1 leaks MAC addresses; v4 is preferred for most use cases).
Testing custom UUID generation logic or new library integrations to ensure RFC 4122 compliance.
Auditing exported data or logs that contain UUIDs to verify they are all well-formed.
Comparing two UUIDs to see if one is nil (all zeros) or check if they share the same version.
Learning UUID structure by pasting examples and seeing which digits encode version and variant.
How to use UUID validator
One input field, instant validation feedback.
Paste or type the UUID: Paste a UUID string into the input field. The standard format is 8-4-4-4-12 hexadecimal digits with hyphens, e.g., 550e8400-e29b-41d4-a716-446655440000.
Read the validation result: The tool immediately shows whether the UUID is valid. If valid, it displays the version (v1, v3, v4, or v5) and variant. If invalid, it explains why — wrong length, missing hyphens, invalid characters, or bad variant bits.
Check the version: v1 = time-based (includes timestamp and MAC address); v3 = MD5 hash of a namespace and name; v4 = random (most common); v5 = SHA-1 hash of a namespace and name. The version appears in the third group, first digit.
Verify the variant: RFC 4122 UUIDs have variant 10x (hex 8, 9, a, b in the 17th position). Other variants exist but are rare and non-standard.
Test multiple UUIDs: Clear the input and paste the next UUID. Validation is instant for each one.
Key features
RFC 4122 compliance check: Validates the 8-4-4-4-12 format, hyphen placement, hexadecimal characters, version field, and variant bits per the standard.
Version identification: Detects v1 (time), v3 (MD5), v4 (random), and v5 (SHA-1) by reading the version digit.
Variant field validation: Confirms the variant bits are set to 10x (RFC 4122 standard). Non-standard variants are flagged.
Nil UUID detection: Recognizes the all-zeros UUID (00000000-0000-0000-0000-000000000000) as valid and displays 'nil UUID'.
Case insensitive: Accepts lowercase, uppercase, or mixed-case UUIDs — all are valid per the spec.
Instant feedback: Validation happens as you type or paste, with immediate error explanations.
Common use cases
API debugging: Verify that an ID returned by an API is a valid UUID before using it in subsequent requests.
Database query troubleshooting: If a UUID foreign key lookup fails, validate the UUID to rule out formatting issues.
Form input validation: Check user-provided UUIDs in admin panels, import forms, or API testing tools.
Library testing: Validate output from a UUID generation library to ensure it produces RFC 4122 compliant UUIDs.
Version auditing: Identify which UUID version your system uses — v1 includes MAC addresses (privacy concern); v4 is recommended.
Learning UUID structure: Paste examples and see which digits encode version and variant fields.
Examples
Actual validation results from this tool.
Valid UUID v4 (random)
550e8400-e29b-41d4-a716-446655440000
✓ Valid UUID v4 (random)
The 13th digit is '4' (version 4 = random), and the 17th digit is 'a' (variant 10x = RFC 4122). All hyphens are in the correct positions.
Valid UUID v1 (time-based)
c232ab00-9414-11ec-b909-0242ac120002
✓ Valid UUID v1 (time-based)
The 13th digit is '1', indicating a time-based UUID. These include a timestamp and MAC address, so they are sortable but leak hardware info.
Nil UUID (all zeros)
00000000-0000-0000-0000-000000000000
✓ Valid UUID (nil)
The all-zeros UUID is valid per RFC 4122 and is used as a placeholder or to represent 'no value'.
Invalid: missing hyphens
550e8400e29b41d4a716446655440000
✗ Invalid: wrong length (expected 36 characters with hyphens)
UUIDs must have hyphens at positions 8, 13, 18, and 23. This is 32 characters without hyphens.
Invalid: non-hex character
550e8400-e29b-41d4-g716-446655440000
✗ Invalid: contains non-hexadecimal character 'g'
All non-hyphen characters must be 0-9 or a-f (case insensitive). 'g' is not valid hex.
Technical reference
The UUID format and standards this tool validates against:
Specification
RFC 4122 — A Universally Unique IDentifier (UUID) URN Namespace
Format
8-4-4-4-12 hexadecimal digits with hyphens (36 characters total), e.g., 550e8400-e29b-41d4-a716-446655440000
Version field
13th hex digit (first of third group). 1=time-based, 3=MD5, 4=random, 5=SHA-1
Variant field
17th hex digit (first of fourth group). RFC 4122 requires variant bits 10x, so the digit must be 8, 9, a, or b
Nil UUID
00000000-0000-0000-0000-000000000000 — valid UUID used as a placeholder or default
Case sensitivity
Hexadecimal digits are case-insensitive. Lowercase is conventional but uppercase is equally valid
UUID v1 (time-based)
Encodes timestamp and MAC address. Unique but leaks hardware info; not recommended for public IDs
UUID v4 (random)
122 random bits. Most widely used; no collision risk in practice
UUID v5 (name-based SHA-1)
Deterministic — same namespace + name always produces the same UUID. Useful for reproducible identifiers
Common mistakes to avoid
Storing UUIDs as strings in databases without validation
Why it happens: If your application accepts UUID input without validation and stores it as a VARCHAR or TEXT column, malformed UUIDs (missing hyphens, wrong length, invalid characters) can enter the database. Later queries that assume valid UUID format will fail, and foreign key lookups will return no results because the string does not match. The database does not enforce UUID format for string columns, so garbage in means garbage out.
How to avoid it: Use the validator before inserting UUIDs into the database. Better yet, use a native UUID column type (PostgreSQL UUID, MySQL BINARY(16)) that enforces format at the database level. If you must use strings, add a constraint or trigger that validates the format, or validate in the application layer before every insert.
Using UUID v1 for public-facing identifiers
Why it happens: UUID v1 encodes the current timestamp and the MAC address of the generating machine. This leaks hardware information — an attacker can infer your server's network card and the exact time the UUID was created. For user IDs, session tokens, or public resource identifiers, this is a privacy and security risk. Additionally, v1 UUIDs are sortable by creation time, which can leak information about user growth or activity patterns.
How to avoid it: Use UUID v4 (random) for public identifiers. It has 122 random bits and no embedded metadata. If you need deterministic UUIDs (same input produces same UUID), use UUID v5 (SHA-1 hash) with a secret namespace, not v1.
Comparing UUIDs case-sensitively
Why it happens: Hexadecimal digits are case-insensitive, so '550e8400-e29b-41d4-a716-446655440000' and '550E8400-E29B-41D4-A716-446655440000' are the same UUID. If your code compares UUIDs as raw strings with a case-sensitive comparison, they will not match, causing lookups to fail even though the IDs are logically identical.
How to avoid it: Normalize UUIDs to lowercase (or uppercase) before comparison. Most UUID libraries do this automatically. If comparing strings directly, use a case-insensitive comparison or .toLowerCase() in JavaScript, .lower() in Python, etc.
Assuming all 36-character strings are valid UUIDs
Why it happens: A string with the right length and hyphens in the right places can still be invalid if it contains non-hex characters, or if the version or variant bits are wrong. For example, '550e8400-e29b-71d4-a716-446655440000' has '7' as the version digit, which is not a defined UUID version. Silently accepting it can cause issues when the ID is used with systems that expect strict RFC 4122 compliance.
How to avoid it: Always validate the version and variant fields, not just length and hyphen placement. Use this tool or a UUID validation library rather than a regex that only checks format.
Generating UUIDs client-side without checking for collisions
Why it happens: UUID v4 has 122 random bits, so the collision probability is astronomically low — but not zero. If a broken random number generator is used (e.g., a seeded PRNG with low entropy, or a polyfill with poor randomness), collisions become likely. Databases with unique constraints will reject duplicate UUIDs, but without the constraint, duplicate IDs silently corrupt data.
How to avoid it: Use a well-tested UUID library (crypto.randomUUID() in modern browsers, uuid package in Node.js) rather than rolling your own. Add a unique constraint on UUID columns in the database to catch collisions. If generating millions of UUIDs, monitor for duplicates in logs.
Frequently asked questions
How do I tell which UUID version a string is?
Look at the 13th character (the first digit of the third group after the second hyphen). If it is '1', the UUID is v1 (time-based). If '3', it is v3 (MD5 hash). If '4', it is v4 (random). If '5', it is v5 (SHA-1 hash). For example, in '550e8400-e29b-41d4-a716-446655440000', the 13th character is '4', so it is a v4 UUID.
What is the difference between UUID v1 and v4?
v1 (time-based) encodes a timestamp and the MAC address of the generating machine. It is sortable by creation time but leaks hardware and timing information. v4 (random) is 122 bits of randomness with no embedded metadata. It is not sortable but has no privacy leaks. Use v4 for almost all cases; use v1 only if you need time-sorted IDs and control the environment (e.g., internal database keys).
Are UUIDs case-sensitive?
No. Hexadecimal digits (0-9, a-f) are case-insensitive, so 'a' and 'A' represent the same value. The UUIDs '550e8400-e29b-41d4-a716-446655440000' and '550E8400-E29B-41D4-A716-446655440000' are identical. Convention is to use lowercase, but uppercase is equally valid. Always normalize to one case before comparison.
What is the nil UUID and when is it used?
The nil UUID is '00000000-0000-0000-0000-000000000000' (all zeros). It is a valid UUID per RFC 4122 and is used as a placeholder, default value, or to represent 'no ID'. For example, an optional foreign key that is not set might be stored as the nil UUID instead of NULL.
Can I validate UUIDs without hyphens?
This tool requires the standard 8-4-4-4-12 hyphenated format (36 characters). Some systems store UUIDs as 32-character hex strings without hyphens. To validate those, add hyphens at positions 8, 13, 18, and 23 first, or use a library that accepts both formats. The hyphenated form is the canonical representation per RFC 4122.
What are the variant bits and why do they matter?
The variant bits (first two bits of the 17th hex digit) indicate which UUID layout is used. RFC 4122 UUIDs have variant 10x in binary, which maps to hex digits 8, 9, a, or b. Other variants exist (Microsoft GUID, NCS backward compatibility) but are rare. If the variant is wrong, the UUID may be from a different system and may not parse correctly in tools expecting RFC 4122.
Should I use UUIDs or auto-incrementing integers for database primary keys?
UUIDs: distributed systems friendly (no central ID server needed), no information leakage (v4 is random), portable across databases. Integers: smaller (4–8 bytes vs 16), faster indexing, sortable by insertion order. Use UUIDs for distributed systems, public APIs, or when merging data from multiple sources. Use integers for single-database apps where simplicity and performance matter more.