Snowflake ID Decoder
NewDecode Twitter/X or Discord-style Snowflake IDs into their embedded timestamp, worker/datacenter ID, process ID, and sequence number, with selectable epochs.
A Snowflake ID packs a millisecond timestamp (relative to a service-specific custom epoch), a worker/datacenter identifier, and a per-millisecond sequence counter into a single 64-bit integer — which is why these IDs sort chronologically and embed their own creation time, unlike a random UUID.
Frequently Asked Questions
Why do Discord and Twitter IDs need a different epoch?
Each service defines its own "custom epoch" as the zero point for the embedded timestamp so IDs fit comfortably in a 64-bit integer for that service's lifetime; Discord uses Jan 1, 2015 while Twitter/X uses Nov 4, 2010, so decoding the same raw number against the wrong epoch gives the wrong date.
Can I get the exact creation time of a Discord message from its ID alone?
Yes — Discord message, user, and channel IDs are all Snowflakes, so the top 42 bits (after shifting right by 22) give a millisecond-precision timestamp relative to the Discord epoch, which this tool converts straight to an ISO date.
What do the worker ID, process ID, and sequence fields mean?
They identify which server process generated the ID and in what order: worker ID and process ID together identify the generating machine/process, and the 12-bit sequence number disambiguates multiple IDs generated within the same millisecond by that same process.
Is this the same format as a Twitter Snowflake ID?
The bit layout is nearly identical since Discord's format was explicitly modeled on Twitter's original Snowflake design — the main practical difference for decoding is which custom epoch constant to add back to the extracted timestamp bits.
Does this tool need network access to decode an ID?
No — decoding is pure bit-shifting arithmetic done entirely in your browser using BigInt; no ID is ever sent to a server.