Snowflake ID Decoder (Twitter/Discord)

Snowflake IDs look like a random run of digits, but they are not random at all — most of the ID is a timestamp, with the rest identifying which machine generated it and a per-millisecond counter. Paste a Twitter or Discord Snowflake to pull out its creation time and the worker, process, and sequence fields packed inside.

How to use the Snowflake ID Decoder (Twitter/Discord)

Choose the source so the decoder uses the right epoch — Discord and Twitter count their timestamps from different start dates, so picking the wrong one shifts the decoded time by years. Paste the Snowflake into the box and the breakdown appears instantly: the headline creation time in your local timezone, then a table with the UTC time, raw Unix milliseconds, and each bit-field — worker (or datacenter) ID, process ID, and the per-millisecond sequence counter.

The 64-bit binary view at the bottom shows exactly how the fields are laid out: the high bit is unused, 41 bits hold the timestamp, the next 10 bits hold the machine identifiers, and the low 12 bits hold the sequence. Use Copy UTC time to grab the decoded timestamp. If the ID is not a valid Snowflake — non-numeric, or too large for 64 bits — an error message explains what is wrong.

Decoding happens locally with 64-bit-safe big-integer math, so IDs are never sent anywhere and very large values are handled exactly.

What a Snowflake ID encodes

A Snowflake is a 64-bit ID designed by Twitter to generate unique identifiers across many servers without any central coordinator. The trick is to pack meaning into the bits. The most significant bit is always zero (so the value stays positive), the next 41 bits store a millisecond timestamp measured from a fixed custom epoch, the following 10 bits identify the machine that created the ID, and the final 12 bits are a sequence number that increments when the same machine generates more than one ID in the same millisecond. Add those together and every ID is unique, roughly time-ordered, and traceable to its source — all without a database round trip.

The custom epoch is the detail that trips people up. Twitter counts from 4 November 2010 and Discord from 1 January 2015, so the same 41-bit timestamp decodes to completely different real-world times depending on which system minted it. That is why this tool asks you to choose the source. Once the epoch is right, the timestamp is simply added back to it to recover the creation time, which is accurate to the millisecond — a genuinely useful property, since it means a Discord message or tweet ID tells you exactly when it was created.

The 10 machine bits are split slightly differently by each platform — Twitter used 5 bits for a datacenter ID and 5 for a worker ID, while Discord labels them worker and process IDs — but the layout is otherwise identical. Because the timestamp sits in the high bits, sorting Snowflakes numerically also sorts them chronologically, which is why they make excellent primary keys. They are not secret or random, though: anyone can read the embedded creation time, so a Snowflake should never be treated as an unguessable token.

Common use cases

• Finding when something was created. Recover the exact timestamp of a Discord message, user, or channel, or a tweet, straight from its ID.
• Debugging distributed systems. Read the worker and sequence fields to see which node generated an ID and in what order.
• Bot and API development. Verify that IDs you generate or receive decode to sensible times and machine numbers.
• Data forensics. Order or date records by the timestamp embedded in their Snowflake keys.