UUID v7 Timestamp Decoder
Extract the millisecond timestamp embedded in the first 48 bits of a UUID v7, converting it back to a UTC date and time by simply pasting the string. Detects non-v7 versions and variant anomalies, and works as the reverse of the sibling UUID v7 Generator tool.
UUID v7 bit layout
| Bit range | Field | Description |
|---|---|---|
| 0-47 | unix_ts_ms | Milliseconds since the Unix epoch, stored big-endian. The value this tool extracts. |
| 48-51 | version | The UUID version number. Fixed to 0111 (7 in hex) for v7. |
| 52-63 | rand_a | 12 bits of random data. Some implementations use it to preserve ordering within the same millisecond. |
| 64-65 | variant | Fixed value 10 indicating the RFC 4122/9562 variant. The first hex digit becomes 8/9/a/b. |
| 66-127 | rand_b | 62 bits of random data, providing entropy to avoid collisions. |
What extracting a UUID v7 timestamp means
UUID v7, standardised in RFC 9562 in 2024, embeds the moment of creation in its first 48 bits as a Unix timestamp in milliseconds. That is why sorting a set of them puts them in creation order, and why using them as database primary keys keeps index fragmentation low. Paste a UUID here and this tool pulls those 48 bits back out as a UTC date and time.
It also reports the version and the variant. If you paste something that is not a v7, the timestamp is still calculated and shown, accompanied by a warning that the value is not a v7. A random v4 will yield a meaningless date, but seeing that happen is a useful way to understand what each kind of UUID actually carries. A bit-layout table shows what follows those first 48 bits. Everything runs in your browser.
How to read a timestamp out of a UUID
- Paste the UUID The standard 36-character form with hyphens, 8-4-4-4-12. Upper or lower case both work.
- Check the version and variant A v7 produces no warning. Anything else is flagged as not being a v7.
- Read the recovered time It appears three ways: Unix milliseconds, ISO 8601 in UTC, and your own device's local time.
- Look at the bit-layout table You can see what occupies each range of bits after the 48-bit timestamp — the version, the variant and the random portion.
Tips for getting more out of it
- All decoding happens entirely inside your browser's JavaScript — the UUID you enter is never sent to the toolbase.cc server.
- If your database primary key uses UUID v7, you can recover the record's creation time by simply pasting the key here, even without a dedicated created_at column.
- Entering a non-v7 UUID (such as v4) triggers a warning, but the mechanically extracted reference value from the first 48 bits is still shown, which is useful for learning how the formats differ.
- If you need to generate a UUID, use the sibling "UUID v7 Generator" tool — it produces UUIDs that this tool can decode back directly.
- Pasting UUID v7 values found in log files or API responses one at a time is a handy way to estimate when events occurred in an external system during debugging.
Where this helps
Recovering when a logged event happened
Even a log with no timestamp column can be dated if its primary keys are v7, which helps when you are reconstructing the order of events during an incident.
Confirming that keys really sort by creation
Feed in several records' UUIDs in turn and check that the implementation genuinely produces time-ordered values.
Deciding whether to adopt v7
Seeing what can actually be extracted makes the trade-off concrete: the creation time is readable by anyone holding the value, which is a drawback wherever that timing is sensitive.
Telling versions apart
Whether a UUID you received is a v4 or a v7 is hard to judge by eye, and this settles it immediately.
UUID terms explained
- UUID v7
- The version standardised in RFC 9562, carrying a Unix millisecond timestamp in its first 48 bits. Being sortable by time is the main thing that sets it apart from v4.
- Version
- The digit at the 13th hexadecimal position, which states how the UUID was generated. For a v7 it is 7.
- Variant
- A separate value describing the internal layout. In UUIDs following RFC 9562 the 17th position is 8, 9, a or b.
- Unix milliseconds
- Milliseconds elapsed since 1 January 1970 at 00:00:00 UTC. Forty-eight bits are enough to reach the year 10889.
- How v4 differs
- A v4 is essentially all random and **carries no information about when it was made.** It therefore does not sort into creation order, but in exchange its timing cannot be read by anyone.
Frequently Asked Questions
Side Note — Giving UUIDs a built-in clock
What makes UUID v7 groundbreaking is that the identifier itself permanently carries its generation time. With the older UUID v4, a separate created_at column was essential to know when a record was made, but if a table's primary key uses UUID v7, the generation time can be mechanically recovered from the ID string alone. This tool provides that recovery process as the reverse of the sibling UUID v7 Generator tool.
This property is especially useful during incident investigations and data migrations. If an order ID buried in an old log, or an event ID received from an external system, happens to be in UUID v7 format, you can instantly tell roughly when the record was created without consulting a dedicated timestamp column. This also applies to legacy systems missing a created_at column, or to analyzing UUID v7 values issued by another company.
That said, there are caveats. A UUID v7 timestamp depends entirely on the generating machine's clock, so if that server's clock is off, the extracted result will be off too. Also, keep in mind that this tool mechanically extracts a "would-be timestamp" even from other UUID versions like v4 — that is purely an interpretation of bit positions, and does not guarantee the resulting value is meaningful.