Snowflake ID Converter. Discord & Twitter Timestamps

How a snowflake ID is laid out

A snowflake is a 64-bit integer. The sign bit (bit 63) is unused, the next 41 bits are a timestamp in milliseconds since a service-specific epoch, and the remaining 22 bits identify the machine and the request:

• Bits 62–22, timestamp in ms. Shift right by 22 and add the epoch to get the date.
• Bits 21–17. 5 bits: the worker (Discord) or datacenter (Twitter) ID.
• Bits 16–12. 5 bits: the process (Discord) or worker (Twitter) ID.
• Bits 11–0. 12 bits: a per-millisecond sequence counter (0–4095).

Because the timestamp is stored in the most significant bits, snowflake IDs sort in chronological order, which is exactly why so many services use them for primary keys.

Known epochs

• Discord, epoch 1420070400000 ms (2015-01-01 00:00:00 UTC). Worker / process / sequence layout.
• Twitter / X, epoch 1288834974657 ms (2010-11-04 01:42:54.657 UTC). Datacenter / worker / sequence layout.
• Custom, any epoch in milliseconds, for self-hosted snowflake implementations.

Fields, bit-shifted out

• 1535074998682255483 → August 7, 2026 00:00:00.017 UTC (Discord epoch, worker 1048575, process 4095, sequence 4095).
• 1535074998681600000 → August 7, 2026 00:00:00 UTC (Discord epoch, worker 0, process 0, sequence 0; all 22 low bits are zero).
• 0 → exactly the selected epoch, the first ID a service could ever issue.

The first two IDs decode to the same millisecond. Their difference lives entirely in the 22 low bits: worker 1048575 needs 20 bits, so it does not fit the 5-bit worker field of the standard layout; treat this value as a raw bit pattern rather than a real deployment. The pair is here because the two IDs look interchangeable and are not, which is the point of the precision note below.

Shifting out the timestamp in your own code

• JavaScript: (id >> 22n) + 1420070400000n, the timestamp in ms (use BigInt; IDs exceed Number.MAX_SAFE_INTEGER).
• Python: (id >> 22) + 1420070400000, then datetime.fromtimestamp(ms / 1000, tz=timezone.utc).
• Go: time.UnixMilli((id >> 22) + 1420070400000).
• SQL: FROM_UNIXTIME(((id >> 22) + 1420070400000) / 1000). The parentheses around the shift are required: >> binds looser than + in MySQL and PostgreSQL, so id >> 22 + 1420070400000 is parsed as id >> (22 + 1420070400000) and returns garbage.

Gotchas: precision, the 22 low bits, and epoch mismatches

• Precision. IDs are up to 19 digits, larger than JavaScript's safe-integer limit. This converter reads them with BigInt, so nothing is lost. In your own JS, never parse an ID with Number(): the 19-digit ID 1535074998682255483 comes back as 1535074998682255400 once a Number has touched it. Parse IDs as strings and convert with BigInt(id).
• The 22 bits, timestamp is id >> 22 with arithmetic shift; worker is (id >> 17) & 0x1F; process is (id >> 12) & 0x1F; sequence is id & 0xFFF.
• Epochs differ, a Discord ID decoded against the Twitter epoch is off by about four years. Always pick the right preset (or supply the custom epoch).
• Microservices, many self-hosted snowflake forks keep the same 41/5/5/12 layout but change the epoch; the Custom preset covers those.