Snowflake ID Decoder

A Discord ID is a Snowflake with Discord bit widths and the Discord epoch of 1 January 2015, so paste it into this decoder and the epoch is detected automatically. Discord splits the 64 bits as 42 bits of millisecond timestamp offset from its epoch, 5 bits of internal worker ID, 5 bits of internal process ID, and 12 bits of a per-process increment. Every object Discord exposes uses the same scheme, which means the creation time of a user account, a guild, a channel, or a message can be read directly from its ID with no API call. That is genuinely useful for moderation and for debugging ordering issues, since comparing two message IDs numerically tells you which was sent first without fetching either message. Note that the worker and process fields are internal to Discord infrastructure and carry no meaning for API consumers, so there is nothing to be learned from them. If the decoded date lands in the early 2010s, the ID has almost certainly been decoded against the Twitter epoch instead: switch the epoch selector to Discord.

Nearly always the epoch. The 41-bit timestamp field is an offset, not an absolute time, so a decoder using the Twitter epoch on a Discord ID reports a date about four years and two months early, and a decoder assuming the Unix epoch on any Snowflake reports a date in the early 1970s. Switch the epoch selector, or enter the correct custom epoch if the ID comes from an in-house generator. A second cause is a non-standard bit layout: some implementations widen the timestamp field or narrow the sequence, so reading the standard 41-bit slice picks up bits that belong to a neighbouring field and produces a date that is wrong in an unobvious way. A third cause is precision loss in JavaScript, which is worth checking before blaming the decoder. A 64-bit Snowflake exceeds the 53 bits of integer precision a JavaScript number can hold exactly, so any code path that parses the ID with JSON.parse or Number and then re-serialises it will silently corrupt the low digits. Keep Snowflakes as strings or BigInt end to end, and confirm that the value you pasted still matches the source.

A Snowflake is not a secret and should never be treated as one. Every field is derived from public or low-entropy information: the timestamp is the wall clock, the datacenter and worker identifiers are small integers, and the sequence is a counter starting at zero each millisecond. Given one valid ID, an attacker can construct plausible neighbouring IDs by adjusting the timestamp and sequence, and in a system that assigns sequential IDs to sequential records those guesses will frequently hit real objects. This makes Snowflakes unsuitable as capability tokens, unguessable share links, or password reset identifiers, all of which need cryptographic randomness rather than structure. The correct use is as a primary key or event identifier behind a proper authorisation check, where being guessable does not matter because the server verifies that the caller may access the object. The same reasoning applies in reverse: because the timestamp is readable by anyone, publishing Snowflakes discloses exactly when each record was created and, by comparing sequence numbers across a time window, roughly how many records you are creating.