ID Decoder

Paste a string and every format that can parse it gets a card. Most of them hide a creation time somewhere in the first few bytes, which is the interesting part.

• UUID, any version, plus the nil and max forms. v1, v2 and v6 give up a timestamp and the MAC address of the machine that minted them. v7 gives up a millisecond timestamp.
• ULID and KSUID: a timestamp followed by randomness, so you get the moment of creation.
• TypeID: the type prefix, the UUIDv7 underneath it, and that v7's timestamp.
• ObjectID: MongoDB's 12 bytes, which start with a second-resolution timestamp and end with a counter.
• Snowflake: the timestamp, worker, process and sequence packed into a 63-bit integer by Twitter, Discord and plenty of others since.
• Cuid, Cuid2 and Nano ID, which mostly means confirming the shape and the alphabet.

A Nano ID is random from end to end. So is a UUID v4, apart from six bits that say which version it is. Cuid2 runs its inputs through a hash before you ever see it. There is nothing to recover from any of them, and that is exactly what they were built for: an ID that leaks no creation time, no machine identity, and no ordering.

If a decoder ever tells you it found a timestamp inside a v4, it invented one.

A snowflake stores milliseconds since an epoch that the ID itself never names. Twitter counts from 2010, Discord from 2015, Instagram from 2011. The same 63 bits therefore mean a different instant depending on who handed the ID to you.

So the card lists one reading per well-known epoch. Pick the row that matches the system the ID came from.

All of this runs as JavaScript in your browser. No ID you paste here reaches a server, ours or anyone else's, so pasting a production identifier is safe.

Holding a UUID and only want the RFC details? The UUID decoder covers that on its own.