Introduction
Auto-incrementing IDs do not work when you have a hundred servers writing to the same database. Twitter ran into this problem at scale and answered it with Snowflake, a 64-bit ID format that packs a timestamp, a worker ID, and a sequence number into a single integer. The result is roughly sortable by time, unique across machines without coordination, and small enough to fit in a BIGINT column. This snowflake id generator produces Twitter-style Snowflake IDs in your browser and decodes any Snowflake you paste back into its timestamp, worker, datacenter, and sequence parts. No data leaves your device.
What this tool does
- Generates 64-bit Snowflake IDs using the Twitter layout: 41-bit millisecond timestamp, 5-bit datacenter ID, 5-bit worker ID, 12-bit sequence.
- Supports configurable worker ID (0-31) and datacenter ID (0-31) so you can simulate IDs from different nodes.
- Accepts a custom epoch in milliseconds, defaulting to the Twitter epoch (1288834974657, 2010-11-04). Discord's epoch (1420070400000, 2015-01-01) is a common alternative.
- Generates up to 100 IDs in one batch, with sequence incrementing within the same millisecond.
- Decodes any pasted Snowflake ID into its timestamp (ISO date), datacenter ID, worker ID, and sequence.
- Runs entirely client-side using BigInt arithmetic and crypto-grade randomness from the browser.
How this tool works
Set the worker ID and datacenter ID to match the node you want to simulate. Set the custom epoch to match your system: Twitter uses 1288834974657, Discord uses 1420070400000, and many internal systems use 0 or the project launch date. Click Generate to produce one or more Snowflake IDs.
The generator computes the current millisecond timestamp, subtracts the custom epoch, and packs it into the top 41 bits. The datacenter ID and worker ID occupy the next 10 bits. The bottom 12 bits are a sequence counter that increments when multiple IDs are generated within the same millisecond, rolling over to 0 and bumping the timestamp if it overflows. Paste any Snowflake ID into the input field to decode it back into its components.
How Snowflake IDs work
Snowflake was designed by Twitter engineers and open-sourced in 2010. The 64-bit layout is fixed:
| Bits | Field | Range | |---|---|---| | 63 (sign) | 0 | always 0 (positive) | | 22-62 (41 bits) | milliseconds since custom epoch | ~69 years | | 17-21 (5 bits) | datacenter ID | 0-31 | | 12-16 (5 bits) | worker ID | 0-31 | | 0-11 (12 bits) | sequence | 0-4095 per ms |
The 41-bit timestamp supports about 69 years from the custom epoch before it overflows. For Twitter that means until roughly 2079. The 10 bits split between datacenter and worker give 1024 unique nodes, which is enough for most deployments. The 12-bit sequence allows 4096 IDs per millisecond per node, which is about 4 million IDs per second per worker.
Snowflake IDs are monotonically increasing within a single worker because the timestamp always moves forward and the sequence increments within a millisecond. Across workers, IDs are roughly sortable by time but not strictly ordered because clocks drift between machines. The original Twitter implementation used ZooKeeper to assign worker IDs and detect clock drift, rejecting IDs if the system clock moved backward.
Discord uses the same layout with a different epoch (2015-01-01). Instagram used a similar 64-bit scheme with 41 bits of timestamp and 13 bits of shard ID. The format is not standardized in an RFC, but the Twitter layout is the de facto reference.
How to use this tool
- Set the worker ID (0-31) and datacenter ID (0-31) to match the node you want to simulate.
- Set the custom epoch in milliseconds. Twitter default is 1288834974657; Discord uses 1420070400000.
- Set the quantity if you need multiple IDs (up to 100).
- Click Generate New Snowflake ID to produce fresh identifiers.
- To decode an existing ID, paste it into the input field. The decoded timestamp, worker, datacenter, and sequence appear in the settings panel.
Real-world examples
Reproducing a Discord message timestamp
A moderator finds a Discord message ID like 175928847299117063 in a log and needs to know when it was sent. They set the epoch to 1420070400000 (Discord's epoch) and paste the ID into the input field. The tool decodes it to a timestamp, datacenter ID, worker ID, and sequence, revealing the message was sent on 2016-04-30 at a specific time. This works because Discord uses the Twitter Snowflake layout with a different epoch.
Simulating a multi-node deployment
A backend engineer is load-testing a sharded order service that uses Snowflake IDs. They set worker ID 0 and datacenter ID 0 to simulate the primary node, generate 50 IDs, then switch to worker ID 1 and generate 50 more. The two batches have different worker ID bits set, confirming the ID assignment logic in their test harness matches what production nodes would emit.
Verifying clock drift handling
A developer implementing a Snowflake-compatible ID generator wants to confirm that sequence rollover works. They generate 5000 IDs in a tight loop and inspect the output. The sequence field wraps from 4095 back to 0 within the same millisecond, and the timestamp increments by 1 ms when that happens. This matches the behavior of the original Twitter Snowflake worker.
Comparison with similar methods
| Method | Complexity | Typical use |
|---|---|---|
| Snowflake (Twitter) | Medium (requires worker ID assignment) | Distributed systems, Discord, Twitter |
| ULID | Low (no coordination, random entropy) | Sortable DB primary keys, single-process |
| UUID v7 | Low (timestamp + random, RFC 9562) | Standard sortable UUIDs |
| NanoID | Low (random, not sortable) | Compact URL-safe IDs |
Limitations or considerations
Snowflake requires unique worker and datacenter IDs per node. If two nodes share the same worker ID, they will produce duplicate IDs. The original Twitter implementation used ZooKeeper for assignment; you must provide your own coordination mechanism. The 41-bit timestamp overflows about 69 years after your custom epoch, so pick an epoch that gives you runway. Clock drift between machines can cause IDs to sort incorrectly across workers, and clock rollback (NTP corrections) can produce duplicate or out-of-order IDs unless you detect and reject them. This tool does not implement clock rollback protection; it uses the browser's Date.now() which is not monotonic.
Frequently asked questions
What epoch does Discord use for Snowflake IDs?
Discord uses 1420070400000, which is 2015-01-01T00:00:00.000Z in milliseconds. Twitter uses 1288834974657 (2010-11-04T01:42:54.657Z). To decode a Discord ID, set the epoch field to 1420070400000 and paste the ID into the input.
How many Snowflake IDs can one worker generate per second?
The 12-bit sequence field allows 4096 IDs per millisecond per worker, which is about 4,096,000 IDs per second. If you exceed that within a single millisecond, the generator bumps the timestamp forward by 1 ms, which can cause the ID's timestamp to drift slightly ahead of real time.
Are Snowflake IDs sortable?
Within a single worker, yes, they are monotonically increasing. Across workers, they are roughly sortable by time but not strictly ordered because clocks drift between machines. If you need strict global ordering, you must sort by timestamp after generation or use a single worker.
Can I use Snowflake IDs as database primary keys?
Yes. They fit in a 64-bit BIGINT column, are roughly sortable by time which helps B-tree index locality, and are unique across machines without coordination (as long as worker IDs are unique). Many sharded databases use Snowflake-style IDs for exactly these properties.
Conclusion
Snowflake IDs are the right choice when you need unique, roughly sortable IDs across multiple machines without a central coordinator. This generator matches the Twitter layout and supports custom epochs for Discord and other systems. For single-process sortable IDs, the ULID generator is simpler. For compact non-sortable IDs, try the NanoID generator.