Snowflake ID Generator + Decoder

Q: Can I get the real user or message from a Snowflake?

No. Decoding is structural — it reads the timestamp, machine and sequence from the bits, never calling Twitter or Discord. Nothing here returns an account or message, or proves the ID was real.

Q: Why does the same ID show different times on different sites?

Because each site assumes a different epoch. The same 41 bits are one instant under the Discord epoch and another under Twitter's. Set the tool's epoch to whoever minted the ID.

Q: Twitter or Discord epoch — which should I pick?

Pick the issuer: the Twitter epoch (November 2010) for X/Twitter IDs, the Discord epoch (January 2015) for Discord IDs. For your own service, choose a custom epoch and keep it fixed forever.

Q: Are the generated IDs real Discord or Twitter IDs?

No. They are structurally valid Snowflakes with the right bit layout, but no platform issued them, so none resolves on Discord or X. Use them for tests and fixtures, never a real record.

Decode a Snowflake ID to its timestamp, worker and sequence, or generate one for the Twitter or Discord epoch — entirely on this device.

0 bytes uploaded

Epoch

Jump to output

Snowflake IDs

0 IDs

Press ? for shortcuts

Do it offline:$ node -e 'console.log(new Date(Number(BigInt(process.argv[1])>>22n)+1420070400000))' 175928847299117063

How to use it

Choose Generate or Decode with the mode tabs, then pick the Twitter or Discord epoch, or type a custom one.
In Generate, set a worker (0–1023), a start sequence (0–4095) and a count up to 10,000; the same inputs always return the same IDs.
In Decode, paste an ID to read its timestamp, machine split and sequence, then copy a field or share the settings as a link.

A Snowflake is a single 64-bit integer that carries three things at once: a millisecond timestamp, a machine field and a sequence counter, printed as a decimal string too long for a JavaScript number to hold. Decode any ID to the moment it was minted plus its worker and sequence, or generate valid IDs against the Twitter or Discord epoch. Every field is computed in this tab, and nothing you paste is uploaded.

Examples

175928847299117063

timestamp = 2016-04-30T11:18:25.796Z (1462015105796 ms)
machine 32 = worker 1 / process 0
sequence = 7

A Discord ID from the developer docs: the high 41 bits are the timestamp, the 10-bit machine field is worker 1 and process 0, and the sequence is 7.

Generate · Discord epoch · sequence 4094 · count 4

A batch of four from sequence 4094. After 4095 the millisecond is full, so the timestamp advances and the sequence resets — the jump to 4194304 is that carry.

9223372036854775808

timestamp = 2084-09-06T15:47:35.552Z (3619093655552 ms)
machine 0 = worker 0 / process 0
sequence = 0
Bit 63 is set: valid as an unsigned 64-bit ID (Discord) but negative as a signed long (Java/Twitter).

Exactly two to the sixty-third power. Discord reads a Snowflake as an unsigned string, so it decodes cleanly; a signed 64-bit long would read the same bits as negative.

Every example on this page is executed against the same engine that powers the tool, on every build.

Gotchas worth knowing

Why the ID travels as a string

A Snowflake uses all 64 bits, but a JavaScript number loses precision above 2^53, so 175928847299117063 would round to the wrong value. Every ID here stays a string and the math runs on BigInt.

The epoch is the whole game

The 41-bit timestamp counts milliseconds from a chosen epoch, not from 1970. The same 175928847299117063 is 2016-04-30T11:18:25.796Z under the Discord epoch but 2012-03-03T13:01:20.453Z under Twitter's. Match the issuer, or the time is fiction.

Ten middle bits, split two ways

Between the timestamp and the sequence sit ten machine bits. Twitter reads them as a 5-bit datacenter and worker; Discord as a 5-bit worker and process. Decode shows the combined value and both halves.

Unsigned ID versus signed long

A valid signed 64-bit long never sets bit 63, capping Java and Twitter's original service at 2^63 − 1. Discord ships unsigned IDs that may use it, so the decoder flags any ID that crosses the line.

Common errors

A Snowflake ID is a whole number — remove non-digit characters.: Decode expects digits only. A stray letter, an ObjectId("…") wrapper or a hidden space trips it, and the field marks the first non-digit.
That number is larger than a 64-bit Snowflake (max 18446744073709551615).: The ceiling is 2^64 − 1, the largest unsigned 64-bit value. A longer paste is refused whole, never truncated, so a bad ID cannot decode to a plausible lie.
Timestamp must be at or after the epoch and within about 69 years of it (41 bits).: Generation refuses a timestamp before the epoch or over 41 bits past it. That roughly 69-year window keeps bit 63 clear, so every ID is valid signed and unsigned.
10,000 is the browser-side cap — need more? script it: `node -e "const e=1420070400000n;let t=BigInt(Date.now()),s=0n;for(let i=0;i<1e5;i++){if(s>4095n){s=0n;t++}console.log(((t-e)<<22n|s++).toString())}"`: Ten thousand IDs is the in-browser limit. Past it the refusal hands you a Node one-liner that prints as many unique IDs as you need.

FAQ

Can I get the real user or message from a Snowflake?