Generate Snowflake

A 64-bit numeric identifier popularised by Twitter — 41 bits of milliseconds since a chosen epoch, 10 bits for the worker ID, and a 12-bit per-millisecond sequence — sortable by creation time and fits in a BIGINT column.

Browser extensions can read all data on this page. Use a private/incognito window with extensions disabled.

Generated · 0 IDs

Options

Quantity

Worker ID

0–1023, must be unique per minting machine.

Epoch

Twitter Starts 2010-11-04 — original Twitter epoch

Discord Starts 2015-01-01 — original Discord epoch

Unix epoch Starts 1970-01-01 — same as Date.now()

Custom… Pick your own start date

This ID

Length 19 digits

Bits 64 (41 timestamp · 10 worker · 12 sequence)

Collision risk low

Features

Time-sortable 64-bit

Collision

Random part No random part

Counted together Generators reusing one worker ID

Built-in guard 4,096 IDs per millisecond per worker

There is no random birthday estimate because Snowflake is structured. A correctly configured worker stays unique; collisions come from worker ID reuse or clock and sequence problems.

Validate and parse Snowflake

Paste an ID

Paste Snowflake

About Snowflake

Use when: you need a numeric ID that fits in a 64-bit integer column and sorts by creation time — the Twitter / Discord pattern.

Avoid when: you cannot guarantee unique worker IDs across every machine that mints them. Snowflakes collide if two workers share an ID.

How it is generated

A Snowflake is a 64-bit integer rendered in decimal — the Twitter / Discord pattern. The top bit is a reserved sign bit kept at 0; the rest is the timestamp, then the worker ID, then the sequence.

Time is measured in milliseconds since a chosen epoch (Twitter 2010-11-04, Discord 2015-01-01, Unix 1970, or whatever you supply). 41 bits buys roughly 69 years from your epoch.

Worker IDs must be unique across every machine that mints IDs — Snowflakes from two workers sharing an ID will collide. The 12-bit sequence resolves bursts within a single millisecond and wraps the clock forward if you exhaust it.

01 Read Date.now() and subtract the chosen epoch in ms.
02 If same-ms as the previous call, increment the 12-bit sequence. If it overflows, bump the timestamp by 1 ms and reset sequence to 0. Otherwise reset sequence to 0.
03 Compose: (timestamp << 22) | (workerId << 12) | sequence.
04 Render the resulting 64-bit number as a base-10 string (always positive, top bit is 0).

Bit layout of the 64-bit value (msb → lsb):

  bit  63        sign (always 0; keeps the number positive)
  bits 62..22    41-bit ms-since-epoch (Twitter / Discord / Unix / custom)
  bits 21..12    10-bit worker ID (caller-supplied, 0..1023)
  bits 11..0     12-bit sequence (resets per ms, increments on same-ms calls)

Compose:
  value = (timestamp << 22) | (workerId << 12) | sequence

Output:
  value.toString(10)    →    "1789723456789012345"
  (1-19 decimal digits, never negative)

All of this runs in your browser. Random bytes come from crypto.getRandomValues, timestamps come from the system clock, and nothing about the generated ID leaves the tab.