ID Timestamp Decoder

Features

• Recognises UUID (v1/v3/v4/v5/v6/v7/v8), ULID, MongoDB ObjectId, Snowflake IDs and Windows FILETIME
• Converts the embedded time to an ISO 8601 date and explains the bit layout
• ⚠️ UUID v1 stores its timestamp out of order in the string (low 32 bits first, high 12 bits last), so reading it sequentially gives a completely wrong number — handled separately here
• ⚠️ Snowflakes are parsed with BigInt: past 2^53 a JavaScript number loses the low sequence bits while the timestamp (high bits) still looks fine, so the error stays hidden
• ⚠️ The Snowflake epoch is an explicit choice (Twitter / Discord / Instagram / Unix epoch), with its effect stated in the result
• ⚠️ ULIDs are checked against the rule most validators miss: the first character must be 0–7 (the two spare bits of a 130-bit encoding must be zero, and anything higher overflows 128 bits). A length-and-alphabet check lets those through and decodes a date decades away
• Lowercase ULIDs, or ones containing I / L / O, are recovered using Crockford’s ambiguity rules (I and L read as 1, O as 0) and flagged as non-canonical
• ObjectId fields are listed separately — four bytes of seconds, five of per-process randomness, three of counter — because ordering within one second comes from those last six characters
• Types without a timestamp, such as v4, say so rather than leaving a blank
• Paste several IDs, one per line, grouped per line

How to use

1. Paste one or more IDs, one per line
2. For a Snowflake, set the epoch it was produced with
3. The result gives the type, the embedded time and the bit-layout explanation

FAQ

Why is there no single Snowflake epoch?

Because Snowflake is a bit layout (timestamp shifted left 22 bits, with machine and sequence in the low bits), not a standard format — every platform picked its own origin. Twitter uses 2010-11-04, Discord 2015-01-01, Instagram 2011-08-24. The same number yields a plausible date under each assumption and never errors, which is why this tool makes you choose and records which one you chose.

What is the difference between UUID v7 and v4?

v4 is entirely random with no structure; v7 puts Unix milliseconds in the first 48 bits, so it sorts by creation time. That matters in a database: a v4 primary key scatters insert points across the whole B-tree, while v7 is close to sequential writes. The cost is that v7 leaks its creation time — if that is sensitive, do not use v7.

Why can the UUID v1 timestamp not be read in order?

Because the spec splits the 60-bit timestamp into three pieces and puts the low 32 bits first: the string runs `time_low` (32 bits), `time_mid` (16 bits), then `time_hi` (12 bits) sharing a field with the version number. Reading it as an in-order integer gives a completely wrong value that still looks like a plausible time and never errors. v6 exists precisely to re-order those three pieces with the high bits first.

Both ObjectId and Snowflake carry a time — what is the difference?

An ObjectId is MongoDB’s 12-byte value: 4 bytes of seconds, 5 bytes of per-process randomness and a 3-byte counter — second precision. A Snowflake is a 64-bit integer with millisecond precision, the remaining bits split between machine ID and sequence. So two ObjectIds minted in the same second cannot be ordered by their own content, while two Snowflakes can.