Snowflake ID Generator

Generate Snowflake IDs: 64-bit, time-ordered identifiers in the format Twitter and Discord made popular, packing a millisecond timestamp, a machine ID and a per-millisecond sequence into a single sortable number. Choose the epoch (Twitter, Discord, Unix or your own), set a machine ID, and generate one or many at once — each broken down into its component bits so you can see exactly how the value is assembled. It all runs in your browser.

How to use the Snowflake ID Generator

Pick the epoch that matches the system you're emulating — the epoch is the zero point the timestamp counts from, and it differs by platform: Twitter's snowflakes count milliseconds since November 2010, Discord's since January 2015. Choose Unix to count from 1970, or Custom date to set your own. Set a machine ID between 0 and 1023 to distinguish IDs minted by different workers, choose how many to generate, and press Generate. Each ID is a decimal number; the first one is broken down below into its timestamp, machine and sequence parts so you can see the packing.

The layout follows the classic Snowflake scheme: the high 41 bits hold milliseconds since the epoch, the next 10 bits the machine ID, and the low 12 bits a sequence counter that increments when more than one ID is created within the same millisecond (allowing up to 4096 per millisecond per machine). Because the timestamp occupies the most significant bits, the IDs sort chronologically as plain integers — newer IDs are always larger — which is the property that makes them so useful as database keys. Note that generation here uses your browser clock and the machine ID you choose, so for a real distributed deployment you'd assign machine IDs centrally to guarantee global uniqueness; this tool is for understanding, testing and generating sample IDs.

How Snowflake IDs work

A Snowflake ID is a 64-bit identifier designed to solve a specific distributed-systems problem: how do many independent servers generate unique IDs, at high speed, without coordinating on every single one — and have those IDs come out roughly time-ordered? Twitter introduced the scheme to replace auto-incrementing database keys, which require a central sequence and become a bottleneck at scale, and Discord, Instagram and many others adopted variants of the same idea. The trick is to compose the ID from independent parts that each guarantee a slice of uniqueness.

The 64 bits are partitioned. The top 41 bits are a millisecond timestamp measured from a chosen epoch — 41 bits covers about 69 years, which is why each platform picks a recent epoch to maximise the usable range. The middle 10 bits are a machine (or worker) ID, allowing 1024 distinct generators to run in parallel without clashing. The bottom 12 bits are a sequence number that resets every millisecond and increments for each additional ID produced within that same millisecond, so a single machine can mint up to 4096 IDs per millisecond. Put together, two IDs differ if they were created in different milliseconds, or on different machines, or at different points in the same millisecond on the same machine — covering every case without any cross-machine communication.

The most valuable side effect of putting the timestamp in the high bits is that the IDs are k-sortable: sorting them as integers sorts them (approximately) by creation time, and you can extract the timestamp straight from the ID without a separate column. That makes them excellent primary keys — index locality is good because new rows append near each other, range queries by time are cheap, and you avoid the contention of a global counter. The trade-offs are real too: the scheme depends on reasonably synchronised, monotonic clocks (a clock running backwards can cause collisions or require the generator to wait), machine IDs must be assigned so no two live generators share one, and the embedded timestamp leaks creation time, which is occasionally a privacy consideration. Understanding the bit layout — which this tool makes visible — is what lets you reason about all of those properties.

Common use cases

  • Sample data. Generate realistic Snowflake IDs for tests, fixtures and API mocks.
  • Understanding the format. See exactly how the timestamp, machine and sequence bits pack into 64 bits.
  • Epoch comparison. Compare how Twitter, Discord and Unix epochs change the encoded value.
  • Decoding intuition. Learn to read a creation time straight out of an ID's high bits.

Frequently asked questions

What is the bit layout of a Snowflake ID?
The classic scheme uses 64 bits: 41 bits for a millisecond timestamp since a chosen epoch, 10 bits for a machine/worker ID (0–1023), and 12 bits for a per-millisecond sequence (0–4095). The timestamp occupies the high bits so the IDs sort chronologically as integers.

Why do different platforms use different epochs?
The 41-bit timestamp only spans about 69 years, so each platform anchors it to a recent date to maximise the usable lifetime. Twitter counts from November 2010 and Discord from January 2015. The epoch must be known to decode the timestamp back into a real date.

Are these IDs guaranteed unique?
Within the scheme's assumptions, yes: IDs differ by time, machine, or sequence. But real uniqueness requires that no two live generators share a machine ID and that clocks are monotonic. This tool uses your browser clock and a machine ID you pick, so it is for testing and learning — production systems assign machine IDs centrally.

Why are Snowflake IDs good database keys?
Because the timestamp is in the high bits, the IDs are roughly time-sortable as plain integers, so new rows cluster together for good index locality, time-range queries are cheap, and you can read creation time from the ID. They also avoid the central-sequence bottleneck of auto-increment keys.

Can I recover the creation time from an ID?
Yes — shift out the low 22 bits to get the milliseconds since the epoch, then add the epoch. The breakdown shown for the first generated ID does exactly this, displaying the decoded timestamp as an ISO date.