UUID Parser
Decode any UUID or ULID into its version, variant, and embedded timestamp
About this tool
The UUID Parser decodes any UUID (v1 through v8) or ULID and tells you exactly what's encoded inside it — the version, the variant, and, for the versions that carry one, the embedded timestamp. Most UUID tools only generate identifiers; this one goes the other direction — paste an ID you already have (from a database row, a log line, an API response) and see what it actually means. Version 1 and version 6 UUIDs encode a 60-bit timestamp counted in 100-nanosecond intervals since October 15, 1582 (the Gregorian calendar's adoption date, chosen by the original UUID spec authors); version 7 UUIDs and ULIDs encode a much simpler 48-bit Unix millisecond timestamp, which is exactly why they've become the preferred choice for sortable database primary keys since 2023 or so. Everything is decoded locally with plain bit arithmetic — no ID, timestamp, or any other data is ever sent anywhere.
When to use it
- →Figuring out roughly when a database row was created from its v7 UUID or ULID primary key, without a separate created_at column
- →Identifying which UUID version a third-party API or library is actually generating
- →Debugging why IDs aren't sorting chronologically (likely v4 — random — instead of v7 or a ULID)
- →Confirming an ID's variant bits look correct before writing a strict validation regex
Tips
- ◆Only v1, v6, and v7 UUIDs (and ULIDs) encode a timestamp — v3, v4, v5, and v8 don't, since they're built from random bytes or a content hash instead.
- ◆v7 UUIDs and ULIDs are both time-ordered and both encode the same kind of Unix-millisecond timestamp — the practical difference is just encoding (hex-with-hyphens vs. Crockford Base32) and that ULIDs are case-insensitive on input.
- ◆A v1 UUID's timestamp reflects the generating system's clock at creation time — if that clock was wrong, the decoded date will be too.
Frequently asked questions
Why do v1 and v6 UUIDs decode to a different-looking timestamp than v7?
v1 and v6 use the original 1980s DCE UUID design: a 60-bit count of 100-nanosecond intervals since October 15, 1582. v7 (and ULID) use a much simpler 48-bit Unix millisecond timestamp, the same format used everywhere else in modern software — which is a big part of why v7 was standardized in 2024 as the preferred time-ordered UUID version.
What's the difference between a UUID variant and a UUID version?
The version (a single hex digit) says how the UUID was constructed — random, time-based, name-hash-based, etc. The variant (encoded in the first 1-3 bits of a different field) says which layout specification the UUID follows — almost everything you'll encounter is the standard RFC 4122 / RFC 9562 variant; the others (NCS, Microsoft) are legacy and rare today.
Can I trust the timestamp decoded from a random-looking UUID?
Only if it's actually a v1, v6, or v7 UUID (check the version this tool reports first). Running this decoder against a v4 (random) UUID will either fail validation or, worse, produce a meaningless date computed from what are actually random bits — always confirm the version before trusting a decoded timestamp.