Snowflake ID Decoder
Decode a 64-bit Snowflake ID under an explicit provider layout (Twitter/X, Discord, Instagram, or a custom epoch): timestamp, worker, and sequence bits.
This tool handles input and primary processing in your browser and is designed not to send the input to QuickKit’s server.
Decoded fields
| Timestamp (UTC) | — |
|---|---|
| Timestamp (Unix ms) | — |
| Milliseconds since epoch | — |
| Epoch (Unix ms) | — |
| Layout width (bits used) | — |
| Largest ID for this layout | — |
| Datacenter ID | — |
| Worker ID | — |
| Process ID | — |
| Logical shard ID | — |
| Sequence | — |
| Increment | — |
| ID (decimal) | — |
| ID (hex) | — |
| ID (binary, 64-bit) | — |
How it works
A Snowflake ID is a 64-bit, roughly time-ordered number: high bits hold milliseconds since a service-specific epoch, then bits identifying the generating machine or shard, then a per-millisecond sequence counter. The epoch and the bit split differ per service, so the layout is chosen, not guessed — the same number decodes to a different time and different fields under each. Twitter/X uses epoch 1288834974657 with a 41-bit time, 5-bit datacenter, 5-bit worker, and 12-bit sequence. Discord uses epoch 1420070400000 with a 42-bit time, 5-bit worker, 5-bit process, and 12-bit increment. Instagram uses epoch 1314220021721 with a 41-bit time, 13-bit logical shard, and 10-bit sequence. "Custom epoch" applies the Twitter/X bit layout with an epoch you supply. Twitter/X and the custom layout use 63 bits (bit 63 stays an unused zero); Discord and Instagram use all 64. An ID that sets bits above the layout's width is rejected rather than shifted so that an unused leading bit is misread as extra timestamp — if that happens, check the provider. The decoder shows only what the chosen layout encodes; it cannot confirm which service actually issued an ID, and the machine or shard numbers describe internal generators, not accounts or users.