Snowflake ID Generator

About this tool

The Snowflake ID Generator creates 64-bit integer IDs in the Snowflake format, originally developed by Twitter (now X) and widely adopted by Discord, Instagram, Mastodon, and other high-volume distributed platforms. A Snowflake ID packs a 41-bit millisecond timestamp, a 10-bit machine/worker ID, and a 12-bit sequence number into a 64-bit integer. This makes Snowflakes time-ordered, unique across nodes, and generatable at up to 4096 IDs per millisecond per node with no coordination required. On the Generate tab you set the epoch (Twitter's 1288834974657 by default) and a Machine ID from 0 to 1023, then click Generate for one ID or Generate 5 for five IDs with sequence numbers 0-4, shown in decimal with a Copy button. The Decode tab extracts the UTC timestamp, machine ID and sequence from any Snowflake using the epoch you enter, for example Discord's 1420070400000.

Why use it

• Generates time-ordered 64-bit integer IDs compatible with Discord, Twitter formats.

• Decodes existing Snowflake IDs to reveal embedded timestamp and node info.

• Supports configurable worker ID for multi-node simulation.

• Editable epoch field, so you can match Twitter, Discord or your own service's epoch.

• 64-bit integer storage is half the size of a UUID, reducing primary-key index width substantially in high-volume tables.

How to use

1. On the Generate tab, keep the Twitter epoch (1288834974657) or type another epoch in milliseconds, such as Discord's 1420070400000.
2. Set a Machine ID (0-1023) to simulate a specific node.
3. Click Generate for one ID at the current time, or Generate 5 for five IDs in the same millisecond with sequence 0-4.
4. Click Copy next to an ID to copy its decimal value.
5. Switch to the Decode tab, paste any Snowflake ID, enter the epoch of the system it came from, and click Decode to see its Timestamp, Machine ID and Sequence.

When it helps

• Building high-throughput distributed systems that need time-ordered IDs.
• Decoding Discord or Twitter Snowflakes to find creation timestamps.
• Learning the Snowflake ID format for implementation in your own system.
• Generating compatible IDs for testing Snowflake-aware APIs.
• Forensic analysis on Discord or Twitter data exports where you need to reconstruct message timing from the ID alone.

Examples

Decode: 1724795348972474368, Epoch: 1288834974657

Timestamp: 2023-11-15T14:23:51.000Z
Machine ID: 1
Sequence: 0

Decode: 175928847299117063, Epoch: 1420070400000

Timestamp: 2016-04-30T11:18:25.796Z
Machine ID: 32
Sequence: 7

Decode: 1700000000000000000, Epoch: 1288834974657

Timestamp: 2023-09-08T04:15:59.129Z
Machine ID: 672
Sequence: 0

Epoch: 1288834974657, Machine ID: 5, Generate 5 at 2023-11-15T14:23:51.000Z

1724795348972490752
1724795348972490753
1724795348972490754
1724795348972490755
1724795348972490756

Tips

• Pick a Snowflake epoch and document it in source control — once IDs are minted, you cannot change the epoch without breaking timestamp decoding for existing rows.
• Worker IDs must be globally unique across all generators in the same cluster. A common pattern is reading them from environment variables baked at deploy time.
• If you need more than 4096 IDs per millisecond per node, you must add nodes (not raise the sequence width); that limit is a structural property of the 12-bit sequence field.
• Treat Snowflake IDs as 64-bit integers in storage but always serialize as strings in JSON — JavaScript loses precision above 2^53, and a numeric IEEE 754 will mangle them.
• Decoding a Snowflake gives you the creation time exactly because the timestamp is embedded; this is invaluable for incident forensics on Discord or Twitter data dumps.
• Do not reuse worker IDs after a host is decommissioned for at least one full epoch wraparound period; clock-skew bugs can otherwise surface long after the host is gone.
• When building your own Snowflake service, monotonic clock readings (CLOCK_MONOTONIC) prevent NTP corrections from minting duplicate IDs after the wall clock jumps backward.

Frequently Asked Questions

Glossary

Snowflake ID

A 64-bit unique identifier format introduced by Twitter in 2010, structured as a timestamp + worker ID + sequence number.

Snowflake epoch

A custom Unix-millisecond starting point from which Snowflake timestamps are measured. Twitter's default is 2010-11-04T01:42:54.657Z.

Machine/Worker ID bits

The 10 bits in the middle of a Snowflake (5 datacenter, 5 worker) that uniquely identify the generating node, supporting 1024 workers.

Sequence number

The trailing 12 bits incremented within a single millisecond on a single worker, allowing 4096 IDs per worker per millisecond.

Clock skew

Drift between the wall clocks of multiple Snowflake workers; large skew can cause ID ordering or duplicate-issuance bugs.

Twitter Snowflake vs Discord Snowflake

Both use the same bit layout but different epochs (Twitter 2010-11-04, Discord 2015-01-01). Decoding requires the matching epoch.

BigInt

JavaScript's native arbitrary-precision integer type, required for Snowflake math because IDs exceed Number's safe 2^53 limit.