UUID v7 to Timestamp
A UUID looks like a random string, but a version 7 one quietly encodes the moment it was created. Paste any UUID and instantly see its embedded creation time, a bit-by-bit breakdown, and a ready-to-paste query for finding rows by date.
What's inside a UUID v7?
A UUID — universally unique identifier — is a 128-bit value usually written as 32 hex characters split into five groups, like 018c7e69-6f4e-7abc-9def-0123456789ab. Most of that looks random because most of it is — but version 7, standardized in 2024, deliberately puts a 48-bit Unix millisecond timestamp in the first 12 characters. Every v7 UUID quietly carries the moment it was generated.
A few things trip people up when reading that timestamp. It's precise only to the millisecond, not the microsecond a database column might store. It reflects when the ID was generated — practically always row creation — and never changes later. And older UUID versions carry a timestamp too: v1 and v6 both encode a 100-nanosecond-precision count from a completely different starting point, 1582-10-15, not 1970. This tool recognizes all three and converts them consistently.
Finding rows by date without a created_at column
Because the timestamp lives inside the UUID itself — and a UUID v7 primary key is indexed by default — you can query a date range without a separate created_at column at all. Open the "Generate a UUID v7 for a date-range query" panel above, pick a date, and copy a ready-to-run query for PostgreSQL, Node.js, Python, Java, C#, or PHP.
One caveat: a UUID built this way is for querying only. Its random bits are zero-filled rather than generator-produced, so it isn't guaranteed unique — never insert a row using it as the actual id.
Frequently asked questions
What is a UUID v7?
A 128-bit identifier standardized in RFC 9562 (2024) that starts with a 48-bit Unix millisecond timestamp, followed by a version marker and 74 bits of randomness. Because the timestamp leads, UUID v7 values sort in creation order — unlike UUID v4, which is fully random and scatters unpredictably in a database index.
How do I extract the timestamp from a UUID v7?
The first 12 hex characters (48 bits) are a Unix millisecond timestamp. Strip the dashes, take those 12 characters, and parse them as a hexadecimal integer — that's milliseconds since 1970-01-01. This tool does that instantly and also shows UTC, local time, relative time, ISO 8601, and both Unix units.
Is the UUID v7 timestamp accurate to the microsecond?
No — only to the millisecond. If it looks slightly off from a database created_at column, that's expected: Postgres timestamptz stores microseconds, one order of magnitude finer than a UUID v7 can encode. For sub-millisecond ordering, some generators repurpose part of the random bits as a monotonic counter, but that's implementation-specific, not part of the timestamp itself.
Does this tool decode UUID v1 and v6 too?
Yes. Versions 1 and 6 both embed a 60-bit, 100-nanosecond-precision timestamp counted from 1582-10-15 (the Gregorian calendar reform) rather than the Unix epoch — a different field layout in each version, but this tool recognizes both and converts them the same way it does v7.
Why does my UUID show "no embedded timestamp"?
Versions 3, 4, 5, and 8 don't carry one, by design — v4 is fully random, v3/v5 are generated from a name hash (MD5/SHA-1), and v8 is a vendor-defined format this tool doesn't know how to unpack. You'll also see this if the UUID's variant bits don't match the standard RFC 9562 layout, which usually means the value isn't a genuine UUID of the version its nibble suggests.
Can I query my database by date using just the UUID v7?
Yes. Because the timestamp is embedded directly in a UUID v7 primary key, and that key is indexed by default, you can query a date range without a separate created_at column or index. Use the range-query generator on this page to get a ready-to-paste query for PostgreSQL, Node.js, Python, Java, C#, or PHP.
Can I create my own UUID v7 with a custom timestamp?
You can, but only for querying — never for inserting a new row. A hand-built UUID's random bits are zero-filled rather than generated, so it isn't guaranteed unique the way a real generator's output is; using it as a real primary key risks a collision with another zero-filled value built for the same millisecond.
Is UUID v7 actually better for database primary keys than UUID v4?
For most workloads, yes. Because v7 values are time-ordered, new rows insert at the end of a B-tree index instead of scattering randomly across it — this keeps indexes more compact and writes faster at scale, which is why Postgres 18 added a built-in uuidv7() function and most major language standard libraries now support generating v7 directly.