What the validator checks
A UUID is valid when it has exactly 32 hexadecimal digits, normally written as 8-4-4-4-12 with hyphens. The validator accepts the forms that are used in real systems and tells you which one you pasted:
- Standard:
550e8400-e29b-41d4-a716-446655440000 - No hyphens:
550e8400e29b41d4a716446655440000 - Braces:
{550e8400-e29b-41d4-a716-446655440000}, as in GUIDs from Windows - URN:
urn:uuid:550e8400-e29b-41d4-a716-446655440000 - Upper or lower case, and values wrapped in quotes or in a JSON array
Paste several, one per line, and each is checked in a table. If a value is not valid, the message names the problem: a wrong character and its position, a wrong number of digits, or hyphens in the wrong places.
Version and variant
Two fields inside every UUID say what kind it is. The version is the first digit of the third group. The variant is the first digit of the fourth group.
| Third group starts with | Version | Meaning |
|---|---|---|
1 | 1 | Time and node. Contains a creation time. |
3 | 3 | MD5 hash of a name |
4 | 4 | Random |
5 | 5 | SHA-1 hash of a name |
6 | 6 | Reordered time. Contains a creation time. |
7 | 7 | Unix time in milliseconds and random bits. Contains a creation time. |
8 | 8 | Custom |
| Fourth group starts with | Variant |
|---|---|
0 to 7 | NCS, old and reserved |
8, 9, a, b | The standard variant (RFC 4122 and RFC 9562). Nearly all UUIDs are this. |
c, d | Microsoft, reserved |
e, f | Reserved for the future |
The validator reports two things: valid format (32 hex digits in an accepted layout) and RFC 9562 compliant (the standard variant with a version from 1 to 8, or the Nil or Max UUID). A value such as 12345678-1234-1234-1234-123456789012 has a valid format but is not a real RFC UUID, because its version digit is 1 and its variant digit is 1 (not 8, 9, a or b).
Special UUIDs
- Nil UUID:
00000000-0000-0000-0000-000000000000, all zeros. Often used for "no value". - Max UUID:
ffffffff-ffff-ffff-ffff-ffffffffffff, all ones, defined in RFC 9562.
Time inside a UUID
UUIDs of version 1, 6 and 7 hold the moment they were created. The validator shows it in UTC. For version 7 it is the Unix time in milliseconds from the first 12 digits. For versions 1 and 6 it is a count of 100-nanosecond steps since 15 October 1582. Use this to find out when a record was created from its id alone. The same dates on the Unix timestamp converter help when you only have the number.
Validate with a regular expression
// Any UUID of version 1 to 8 with the standard variant (use the i flag)
^[0-9a-f]{8}-[0-9a-f]{4}-[1-8][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$
// Also accept the Nil and Max UUIDs
^(?:[0-9a-f]{8}-[0-9a-f]{4}-[1-8][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}|0{8}-0{4}-0{4}-0{4}-0{12}|f{8}-f{4}-f{4}-f{4}-f{12})$
// Only check the layout, any version
^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$
With a library
// JavaScript (uuid package)
import { validate, version } from 'uuid';
validate(s); version(s);
# Python (raises ValueError when invalid)
import uuid
u = uuid.UUID(s); u.version
// C# (accepts D, N, B and P forms)
Guid.TryParse(s, out Guid g);
// Java: UUID.fromString is lenient and also accepts short groups
// such as "1-1-1-1-1". Check the format with a regular expression first.
// PHP (ramsey/uuid)
\Ramsey\Uuid\Uuid::isValid($s);
Common reasons a UUID is rejected
- It is cut off when copied, so a group is too short.
- It contains a letter after F, a space or a zero-width character copied from a document.
- It has the wrong number of groups, for example a v4 ID with an extra digit.
- It is a different kind of id: a 24-digit MongoDB ObjectId, a 26-character ULID or a hash.
To create UUIDs, use the UUID generator. The guide What is a UUID? explains all the fields.