Snowflake ID Decoder

Decode Snowflake IDs (Twitter, Discord) to extract embedded timestamp, worker, and sequence.

Tested tool guide Tested browser tools Checked August 16, 2026

What Snowflake ID Decoder does, with a checked example

A Snowflake ID is a 64-bit integer that packs three values into one: a millisecond timestamp, a machine identifier, and a per-millisecond sequence counter. This tool splits a Twitter (now X) post ID or a Discord message ID into those fields and shows the timestamp as a UTC calendar date plus milliseconds since the platform's epoch. The thing most people get wrong: neither platform counts from Unix epoch. Twitter's clock starts at 2010-11-04 and Discord's at 2015-01-01, and decoding with the wrong epoch shifts the date by years while still looking plausible. The tool applies the correct epoch for each format, and the ID never leaves your browser.

Worked example

A concrete input and expected output from the current implementation.

Input

457333486387200001

Expected output

Discord snowflake. Timestamp: 2018-06-15 00:00:00.000 UTC. Milliseconds since Discord epoch (2015-01-01T00:00:00Z): 109,036,800,000. Worker: 0. Increment: 1.

The upper 42 bits hold 109,036,800,000 milliseconds, which is exactly 1,262 days after the Discord epoch, landing on 2018-06-15T00:00:00Z. The remaining low bits decode to worker 0 and increment 1.

How the result is produced

Bit layout

Snowflakes are 64-bit integers. Twitter's scheme reserves the top 41 bits for milliseconds since the Twitter epoch, the next 5 for a datacenter ID, the next 5 for a worker ID, and the lowest 12 for a per-millisecond sequence counter. Discord uses 42 timestamp bits, then internal worker and process bits, then a 12-bit increment that rises by one per ID. The tool shifts and masks to read each field.

Epoch conversion

The timestamp field is meaningless without the right starting point. Twitter IDs count milliseconds from 1288834974657, which is 2010-11-04T01:42:54.657Z; Discord IDs count from 1420070400000, which is 2015-01-01T00:00:00Z. The tool adds the matching epoch to the field, converts to a UTC calendar date, and also reports the raw milliseconds. Because the epochs differ, the tool treats the two formats separately rather than applying one constant to every ID.

Good uses

You have a Discord message ID from an API response or log and want the exact millisecond it was created.
You are auditing an old Twitter-era ID and want to see which datacenter and worker generated it, and where it fell in the sequence for that millisecond.
You are reconciling two exported ID lists and need to confirm which entry came first when both display the same second in the interface.

Limits and checks

Epoch mix-ups: decoding a Discord ID with Twitter's epoch, or a Twitter ID with Discord's, shifts the date by roughly four years and still looks valid. Confirm which platform issued the ID before trusting the date.
Field meanings differ by platform: Discord's low bits are internal worker, process, and increment fields, not Twitter's datacenter, worker, and sequence. On most public Discord IDs those internal fields read zero, so a zero result says nothing about any real machine.
A decoded timestamp records what was embedded when the ID was minted, nothing more. IDs can be generated with arbitrary past timestamps, and the format is public, so anyone can fabricate an ID that decodes to any date. Do not treat decoding as proof of provenance.

Common questions

Why is the decoded date off by years from when I think the message was posted?

Most likely the wrong epoch was applied: Discord's clock starts at 2015-01-01, Twitter's in November 2010, and the two differ by more than four years. Check which service issued the ID and decode it as that format. A small discrepancy instead means the ID was generated a moment before the post itself appeared; the embedded time is not always the publication time.

Are snowflake IDs from different services comparable, and does sorting by ID sort by time?

Not directly. Twitter and Discord use different epochs and different field widths, so the raw numbers are not comparable; convert both to milliseconds since their own epochs first. Within one service, IDs are generally sortable by creation time in normal operation, and the sequence field breaks ties within the same millisecond. Beware that some third-party services mimic the format without following it exactly.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.