UUID decoder and generator
Paste a UUID to see its version, variant and, if it has one, the moment it was made, with every bit labelled. It also reads ULIDs, MongoDB ObjectIds and snowflakes, and generates new IDs in your browser.
Any case, with or without dashes, braces or urn:uuid:. The kind of ID is worked out from its length and characters.
More kinds and options: up to 100 at a time, ULIDs, ObjectIds and NanoIDs.
- UTC
- 2022-02-22T19:22:22.000Z
- Your time
- …
- Age
- …
A 48-bit count of milliseconds since 1970, then 74 bits that are random or partly a counter. The time comes first, so these UUIDs sort by creation time and index well in databases.
The bits
| Field | Bits | Value |
|---|---|---|
| Unix time in milliseconds2022-02-22T19:22:22.000Z | 0–47 (48) | 0x017f22e279b0 |
| Versionversion 7 | 48–51 (4) | 0x7 |
| Random (rand_a)random | 52–63 (12) | 0xcc3 |
| Variantbinary 10: RFC 9562 | 64–65 (2) | 0x2 |
| Random (rand_b)random | 66–127 (62) | 0x18c4dc0c0c07398f |
The timestamp counts 1 ms steps from 1970-01-01T00:00:00Z, the Unix epoch. Raw count: 1645557742000.
Generators may use some of rand_a as a sub-millisecond fraction or a counter to keep IDs from the same millisecond in order; from outside, it cannot be told apart from random.
The same 128 bits written as a ULID: 01FWHE4YDGFK1SHH6W1G60EECF. Both start with a 48-bit millisecond time, so the ULID reads back the same moment.
UUID and ID generator
UUID versions 4, 7 and 1, ULIDs, MongoDB ObjectIds, NanoIDs and Discord snowflakes, made in your browser.
Version 4 has no time in it: all 122 bits that are not version or variant are random.
- IDs are generated in your browser once the page has loaded.
How to read a UUID
A UUID is a 128-bit number written as 32 hex digits in groups of 8, 4, 4, 4 and 12. Two digits always mean the same thing whatever made the UUID: the 13th digit is the version, which says how the rest was filled in, and the top bits of the 17th digit are the variant, which says which family of layouts it belongs to. Nearly every UUID in use is the RFC 9562 variant, binary 10, so its 17th digit is 8, 9, a or b.
Everything else depends on the version. Versions 1, 6 and 7 hold a full timestamp, so they can be decoded to a date; version 2 keeps only part of one. Version 4 is random and versions 3 and 5 are hashes, so the most anyone can read from them is the version itself.
| Version | What the bits hold | Time | Sorts |
|---|---|---|---|
| 1 | 60-bit time (100 ns), clock sequence, node (MAC address or random) | Yes | No |
| 2 | DCE security: version 1 with a local user or group ID | Partly | No |
| 3 | MD5 hash of a namespace and a name | No | No |
| 4 | 122 random bits | No | No |
| 5 | SHA-1 hash of a namespace and a name | No | No |
| 6 | Version 1 reordered, time first | Yes | Yes |
| 7 | 48-bit Unix time (ms), then 74 random bits | Yes | Yes |
| 8 | Vendor-defined, only version and variant fixed | Maybe | Maybe |
The variant digit
Only the top one to three bits of the 17th digit are the variant (shown in bold); the rest belong to the next field (shown as x). That is why four different hex digits all mean the standard layout.
| 17th digit | Bits | Variant |
|---|---|---|
| 0 to 7 | 0xxx | NCS (reserved, Apollo Network Computing System) |
| 8 to b | 10xx | RFC 9562 (the standard one) |
| c to d | 110x | Microsoft (reserved, old COM GUIDs) |
| e to f | 111x | reserved for the future |
Worked examples
Version 7 to a date
017f22e2-79b0-7cc3-98c4-dc0c0c07398f
The first 12 hex digits are the time: 0x017f22e279b0 = 1645557742000 milliseconds since 1970, which is 2022-02-22T19:22:22.000Z. The 13th digit, 7, is the version, and the 17th, 9, is binary 1001: variant 10 followed by two random bits. Try it
Version 1 to a date
c232ab00-9414-11ec-b3c8-9f6bdeced846
The time is in three pieces, lowest first. Put them back in order, high, middle, low: 1ec 9414 c232ab00 = 138648505420000000 steps of 100 ns since 1582-10-15. Subtract 122192928000000000 to count from 1970 instead: 16455577420000000, which is 2022-02-22T19:22:22.0000000Z. Try it
Both are examples from RFC 9562, Appendix A, and they hold the same moment. The version 6 example, 1ec9414c-232a-6b00-b3c8-9f6bdeced846, is version 1 with the time pieces put in order, high bits first, which is why it sorts correctly as text and version 1 does not.
ULID, ObjectId, snowflake and NanoID
UUIDs are not the only IDs with a time inside. A ULID is 128 bits like a UUID, 48 bits of milliseconds and 80 random bits, written as 26 characters of Crockford Base32 instead of hex. The alphabet, 0123456789ABCDEFGHJKMNPQRSTVWXYZ, leaves out I, L and O, which are easily confused with 1 and 0, and U, which Crockford dropped to avoid accidental obscenities; a decoder reads I and L as 1 and O as 0. The ULID 01ARYZ6S41TSV4RRFFQ69G5FAV starts with 01ARYZ6S41, which is 1469918176385 ms, 2016-07-30T22:36:16.385Z.
A MongoDB ObjectId is 12 bytes: 4 bytes of Unix seconds, 5 random bytes chosen once per process, and a 3-byte counter. In 507f1f77bcf86cd799439011 the first 8 hex digits, 507f1f77, are 1350508407 seconds, 2012-10-17T21:13:27Z. Snowflakes are 64-bit numbers used by Discord and Twitter/X, with their own epoch; the snowflake ID decoder covers them. A NanoID is 21 random characters and nothing else, so it has nothing to decode.
| Format | Bits | Written as | Time inside | Random | Sorts by time |
|---|---|---|---|---|---|
| UUID v4 | 128 | 36 hex and dashes | none | 122 bits | No |
| UUID v7 | 128 | 36 hex and dashes | 48 bits, 1 ms | 74 bits | To the millisecond |
| UUID v1 | 128 | 36 hex and dashes | 60 bits, 100 ns | none, or a random node | No |
| ULID | 128 | 26 Crockford Base32 | 48 bits, 1 ms | 80 bits | To the millisecond |
| ObjectId | 96 | 24 hex | 32 bits, 1 s | 40 bits per process | To the second |
| Discord snowflake | 64 | up to 20 decimal digits | 42 bits, 1 ms | none | To the millisecond |
| NanoID | 126 | 21 URL-safe characters | none | 126 bits | No |
Common mistakes
- Treating a UUID as a secret. RFC 9562 says not to assume UUIDs are hard to guess or use them as security capabilities. Version 4 from a good random source is unpredictable in practice, but versions 1, 6 and 7 give away when they were made, and a session token deserves a format designed for it.
- Leaking a MAC address. A version 1 UUID made the original way contains the network card address of the machine that made it. Python's uuid1() and PostgreSQL's uuid_generate_v1() still do by default. Some generators, and the one on this page, use a random node with the multicast bit set instead.
- Expecting version 1 to sort. Its time is stored low bits first, so sorting the text does not sort by time. Use version 7, or 6 if you need the version 1 fields.
- Comparing case-sensitively. RFC 9562 allows the hex letters in upper, lower or mixed case, so comparisons must ignore case (the older RFC 4122 asked for lower case output). Store one form and compare that.
- Mixing up GUID byte order. Windows stores the first three groups of a GUID little-endian, so the raw bytes read as a UUID come out with those groups reversed. The text form is the same either way.
Each hex digit is four bits, the way the hex to binary converter shows; turning text into bits is covered by the binary translator.
Questions
Can you get the creation time from a UUID?
From versions 1, 6 and 7, which carry a full timestamp. Version 2 keeps only part of one, and a version 8 may hold one in a layout only its maker knows. Version 7 starts with the Unix time in milliseconds: 017f22e2-79b0-7cc3-98c4-dc0c0c07398f begins 017f22e279b0, which is 1645557742000 ms, 2022-02-22T19:22:22.000Z. Versions 1 and 6 count 100 ns steps from 1582-10-15. Version 4 is random and versions 3 and 5 are hashes, so they hold no time at all.
How do I tell which version a UUID is?
Look at the 13th hex digit, the first one of the third group: in 017f22e2-79b0-7cc3-98c4-dc0c0c07398f it is 7, so it is version 7. The 17th digit, the first of the fourth group, gives the variant; for standard UUIDs it is 8, 9, a or b.
Can a version 3 or 5 UUID be decoded back to the name?
No. They are the first 128 bits of an MD5 or SHA-1 hash with 6 bits overwritten, and a hash cannot be run backwards. The only way to find the name is to guess it, hash the guess with the same namespace, and compare.
Will two random UUIDs ever be the same?
In practice no. A version 4 UUID has 122 random bits, so you would need to generate about 2.7 × 10¹⁸ of them before the chance of any repeat reached one half. That assumes a good random source; the generator on this page uses crypto.getRandomValues.
Which UUID version should I use?
Version 7 for database keys and anything you want sorted by creation time, because new IDs land at the end of an index. Version 4 when the ID should reveal nothing, not even when it was made. Version 5 when the same input must always give the same ID. RFC 9562 recommends 7 over 1 and 6.
What is the difference between a UUID and a GUID?
GUID is Microsoft's name for the same 128-bit identifier, written the same way. The one practical difference is byte order: Windows stores the first three groups little-endian in memory, so the raw bytes of a GUID and the text do not match in the order you would expect.
Are the IDs generated here sent anywhere?
No. They are made in your browser with crypto.getRandomValues when the page loads or an option changes, and are never sent to a server or stored. Decoding is also done entirely in the page.