Snowflake ID Generator — Free Online Tool

Generate and decode Snowflake IDs (Twitter, Discord, Instagram). 64-bit unique IDs with timestamp, worker ID, sequence. Parse creation time from ID.

Use this free online Snowflake ID Generator directly in your browser. No signup required, no data leaves your device. Part of Utilier — a collection of 133+ developer utilities.

What is Snowflake ID Generator & Decoder (Twitter/Discord ID)?

Snowflake IDs are 64-bit unique identifiers used by Twitter, Discord, Instagram, and other distributed systems. Each ID contains: timestamp (milliseconds since epoch), worker/machine ID (which server generated it), and sequence number (for multiple IDs per millisecond). This tool generates Snowflake IDs (new unique IDs) and decodes existing IDs to extract timestamp (convert ID to date/time), worker ID, and sequence. Snowflake IDs are sortable by time (older IDs < newer IDs), collision-resistant (no duplicates across distributed systems), and human-readable (decimal, no special characters). Used for database primary keys, distributed tracing, message IDs, or tweet IDs.

  • Generate Snowflake IDs: Create new 64-bit unique IDs. Each ID is globally unique (no duplicates even across multiple servers). Format: decimal (1234567890123456789) or binary (01010101...).
  • Decode Snowflake IDs: Extract timestamp (when ID was created), worker/machine ID (which server), sequence (counter for same millisecond). Convert Twitter/Discord ID to date/time.
  • Timestamp extraction: Snowflake IDs contain millisecond timestamp. Decode ID → get creation date/time (e.g., ID 1234567890 → 2020-01-15 12:34:56 UTC).
  • Distributed ID generation: Each worker (server) has unique ID (0-1023). IDs from different workers don't collide. Supports horizontal scaling (add more servers without coordination).
  • Sortable by time: IDs are sortable chronologically (older IDs < newer IDs). Useful for pagination, timelines, or sorting by creation time.

Why use snowflake?

Snowflake IDs solve distributed ID generation problems: uniqueness, sortability, and timestamp encoding. Used by Twitter, Discord, Instagram.

  • Unique IDs across distributed systems: No need for centralized ID generator (no single point of failure). Each server generates unique IDs independently. No collisions.
  • Sortable by creation time: IDs are chronologically sortable (older < newer). Great for timelines (Twitter feed), messages (Discord chat), or pagination (ORDER BY id DESC).
  • Extract creation time from ID: No need for separate created_at column. Timestamp is encoded in ID. Decode ID to get exact creation time (millisecond precision).
  • Avoid UUID limitations: UUIDs (128-bit) are not sortable by time (random order). Snowflake IDs (64-bit) are smaller, sortable, and contain timestamp. Faster to index and store.
  • Learn from Twitter/Discord: See how Twitter IDs work (decode tweet ID to timestamp), Discord message IDs (extract creation time), Instagram post IDs.
  • Database primary keys: Use Snowflake IDs as primary keys (sortable, unique, smaller than UUIDs). No auto-increment coordination needed (each server generates IDs independently).

When to use snowflake

Use Snowflake IDs when you need unique, sortable, distributed IDs.

  • Generating unique IDs for distributed systems (multiple servers, no central coordinator).
  • Decoding Twitter IDs to timestamps (when was tweet created? Convert ID to date/time).
  • Parsing Discord message IDs to extract creation time (millisecond precision).
  • Creating database primary keys (sortable, unique, no auto-increment coordination).
  • Building timelines or feeds (sort by ID = sort by time, no separate created_at needed).
  • Distributed tracing (trace IDs with embedded timestamp for debugging).
  • Learning how Twitter, Discord, Instagram generate IDs (reverse-engineer ID format).

How to use snowflake

Generate new ID or decode existing ID.

  1. Choose mode: Generate or Decode: Generate = create new Snowflake ID. Decode = extract timestamp, worker ID, sequence from existing ID (Twitter/Discord ID).
  2. Generate: Set epoch and worker ID: Epoch = reference timestamp (milliseconds since 1970-01-01, or custom epoch like Twitter: 2010-11-04). Worker ID = server ID (0-1023). Sequence auto-increments.
  3. Generate: Click Generate: Tool creates 64-bit Snowflake ID. Format: 41 bits timestamp + 10 bits worker ID + 12 bits sequence. Copy ID (decimal or binary).
  4. Decode: Enter Snowflake ID: Paste Twitter ID (e.g., 1234567890123456789), Discord message ID, or any Snowflake ID (64-bit decimal).
  5. Decode: View extracted data: See: timestamp (milliseconds since epoch), creation date/time (UTC), worker ID (which server), sequence (counter within same millisecond).
  6. Convert to date/time: Tool converts timestamp to human-readable date/time (e.g., 2020-01-15 12:34:56 UTC). Useful for Twitter/Discord ID analysis.
  7. Export or copy: Copy ID (decimal, binary, hex), timestamp, or date/time. Use in code, databases, or documentation.

Key features

  • Generate Snowflake IDs: Create 64-bit unique IDs. Configurable epoch (Twitter: 2010, Discord: 2015), worker ID (0-1023), sequence (0-4095).
  • Decode existing IDs: Extract timestamp, worker ID, sequence from Twitter, Discord, Instagram IDs. Convert ID to date/time.
  • Timestamp extraction: Get exact creation time (millisecond precision) from Snowflake ID. No need for separate created_at column.
  • Sortable IDs: IDs are chronologically sortable (older < newer). Great for timelines, pagination, or sorting by creation time.
  • Multiple formats: Display IDs as decimal (default), binary (64-bit), hex (16 chars), or JavaScript BigInt.
  • Custom epoch: Set custom epoch (Twitter: 2010-11-04, Discord: 2015-01-01). Affects timestamp calculation.
  • Worker and sequence info: See which server (worker ID 0-1023) generated ID and sequence number (0-4095 per millisecond).

Common use cases

  • Decode Twitter ID to timestamp: Twitter ID 1234567890123456789 → decode → creation time: 2020-02-14 12:00:00 UTC. Find when tweet was posted from tweet ID.
  • Decode Discord message ID: Discord message ID 123456789012345678 → creation time: 2015-05-20 08:30:00 UTC. Extract message timestamp from ID.
  • Generate IDs for distributed DB: Each server (worker ID 0, 1, 2...) generates unique IDs. No coordination needed. IDs are sortable by time (ORDER BY id DESC = newest first).
  • Parse Instagram post ID: Instagram uses Snowflake-like IDs. Decode to extract post creation time. Useful for scraping or analysis.
  • Distributed tracing: Generate trace IDs with embedded timestamp. Decode ID to see when request started (no separate timestamp field).
  • Database primary keys: Use Snowflake IDs as primary keys (instead of auto-increment). Sortable, unique, no central coordinator. Scales horizontally.

Examples

Snowflake ID generation and decoding examples.

Generate Snowflake ID (Twitter epoch)

Epoch: 1288834974657 (Twitter epoch), Worker ID: 0, Sequence: 0
ID: 1234567890123456789
Timestamp: 2020-02-14 12:00:00 UTC
Worker: 0
Sequence: 0

New Snowflake ID with Twitter epoch (2010-11-04). Timestamp embedded in ID. Sortable and unique.

Decode Twitter ID to timestamp

Twitter ID: 1234567890123456789
Timestamp: 2020-02-14 12:00:00.000 UTC
Worker ID: 0
Sequence: 789

Extract creation time from Twitter ID. Tweet was posted on 2020-02-14 at 12:00 UTC. Worker 0, sequence 789.

Decode Discord message ID

Discord ID: 175928847299117063
Timestamp: 2016-04-30 11:18:25.796 UTC
Worker ID: 1
Sequence: 0

Discord message created on 2016-04-30. Uses Discord epoch (2015-01-01). Worker 1, sequence 0.

Generate ID for distributed DB

Epoch: 1609459200000 (2021-01-01), Worker ID: 5, Sequence: auto
ID: 5678901234567890123
Timestamp: 2024-03-15 08:45:30 UTC
Worker: 5
Sequence: 123

Database primary key. Worker 5 (server 5) generated ID. Sortable by time (ORDER BY id DESC).

Decode Instagram post ID

Instagram ID: 1234567890123456789
Timestamp: 2018-06-20 15:30:00 UTC
Worker ID: 0
Sequence: 0

Instagram post creation time. Instagram uses Snowflake-like IDs. Useful for scraping or analytics.

Technical reference

Snowflake ID structure (64 bits):

Bit layout
64 bits total: 1 bit unused (always 0), 41 bits timestamp (milliseconds since epoch), 10 bits worker ID (server 0-1023), 12 bits sequence (counter 0-4095 per millisecond).
Timestamp (41 bits)
Milliseconds since custom epoch (e.g., Twitter: 2010-11-04 00:00:00 UTC). 41 bits = ~69 years from epoch. After 2079, Twitter needs new epoch or bit layout.
Worker ID (10 bits)
Server/machine ID (0-1023). Each server has unique ID. Prevents collisions when multiple servers generate IDs simultaneously. Configured per server.
Sequence (12 bits)
Counter (0-4095) incremented for each ID in same millisecond. Resets to 0 on next millisecond. Allows 4096 IDs per millisecond per worker.
Epoch
Reference timestamp. Twitter: 2010-11-04 00:00:00 UTC (1288834974657 ms). Discord: 2015-01-01 00:00:00 UTC (1420070400000 ms). Custom epoch extends ID lifespan (41 bits = 69 years from epoch).
Sortability
IDs are sortable by time (timestamp is most significant bits). Older IDs < newer IDs. Enables ORDER BY id DESC (newest first) without created_at column.
Uniqueness
Combination of timestamp + worker ID + sequence ensures global uniqueness. No duplicates even across distributed systems (as long as worker IDs are unique).
Collision resistance
Each worker generates 4096 IDs per millisecond. If exceeded, wait for next millisecond (1ms). Practically no collisions for typical workloads.
Comparison with UUID
UUID: 128 bits, random, not sortable. Snowflake: 64 bits, sortable, contains timestamp. Snowflake is smaller (better for DB indexes), faster to compare, and sortable.
Decoding formula
timestamp_ms = (ID >> 22) + epoch_ms. worker_id = (ID >> 12) & 0x3FF (10 bits). sequence = ID & 0xFFF (12 bits). Bit shifting extracts each component.

Common mistakes to avoid

Using wrong epoch (default 1970 vs Twitter 2010), causing incorrect timestamps

Why it happens: Snowflake IDs store timestamp relative to epoch. Twitter uses 2010-11-04 (not 1970-01-01). Decoding with wrong epoch gives wrong date/time. Common when decoding Twitter IDs with default epoch.

How to avoid it: Use correct epoch: Twitter = 1288834974657 (2010-11-04), Discord = 1420070400000 (2015-01-01). Tool should allow custom epoch selection. Verify decoded timestamp makes sense.

Reusing worker IDs across servers, causing ID collisions

Why it happens: Each server must have unique worker ID (0-1023). If two servers use same worker ID, they can generate duplicate IDs (same timestamp + worker + sequence). Common when copying configs.

How to avoid it: Assign unique worker ID to each server (server 1 = worker 0, server 2 = worker 1, etc.). Use environment variable or config file. NEVER reuse worker IDs.

Generating >4096 IDs per millisecond per worker, causing sequence overflow

Why it happens: Sequence is 12 bits (max 4095, then wraps to 0). If worker generates >4096 IDs in 1 millisecond, sequence wraps and IDs may collide (same timestamp + worker + sequence). Rare but possible under high load.

How to avoid it: If sequence reaches 4095, wait for next millisecond (1ms sleep). Most systems never hit 4096 IDs/ms (that's 4M IDs/second per worker). If you do, add more workers or use 13-bit sequence.

Storing Snowflake IDs as 32-bit integers, causing overflow

Why it happens: Snowflake IDs are 64-bit (max ~9 quintillion). JavaScript Number is 53-bit (max ~9 quadrillion). 32-bit int is too small (max 2 billion). Storing as 32-bit causes overflow and data loss.

How to avoid it: Use 64-bit integer (SQL: BIGINT, JavaScript: BigInt, Python: int). Or store as string (varchar). NEVER use 32-bit int or float.

Assuming Snowflake IDs are globally unique without unique worker IDs

Why it happens: Uniqueness requires: timestamp + worker ID + sequence. If all workers use worker ID 0, IDs may collide (same timestamp + 0 + same sequence). Worker ID is critical for distributed uniqueness.

How to avoid it: Ensure each server has unique worker ID. Use coordinator (ZooKeeper, etcd) to assign worker IDs dynamically, or configure manually (environment variable).

Frequently asked questions

What is a Snowflake ID?

64-bit unique ID with embedded timestamp, worker ID, sequence. Used by Twitter, Discord, Instagram. Sortable by time, collision-resistant, smaller than UUID.

How do I decode a Twitter ID to timestamp?

Extract timestamp: (ID >> 22) + 1288834974657 (Twitter epoch). Convert to date/time. Example: ID 1234567890123456789 → 2020-02-14 12:00:00 UTC.

What is the difference between Snowflake ID and UUID?

Snowflake: 64-bit, sortable by time, contains timestamp. UUID: 128-bit, random, not sortable. Snowflake is smaller, faster, and sortable.

What is the epoch in Snowflake IDs?

Reference timestamp (milliseconds since specific date). Twitter: 2010-11-04 (1288834974657). Discord: 2015-01-01 (1420070400000). Custom epoch extends ID lifespan (41 bits = 69 years).

How many IDs can Snowflake generate per second?

Each worker: 4096 IDs per millisecond = 4M IDs/second. With 1024 workers: 4B IDs/second. Practically unlimited for most applications.

Can Snowflake IDs collide?

No, if worker IDs are unique and sequence doesn't overflow. Collision requires: same timestamp + same worker ID + same sequence (extremely unlikely with proper configuration).

How do I store Snowflake IDs in database?

SQL: BIGINT (64-bit). JavaScript: BigInt or string. Python: int. NEVER use 32-bit int (overflow) or float (precision loss).

References

Privacy and availability

  • Runs entirely in your browser — zero server processing
  • No signup or account required
  • Works offline once loaded
  • Fast, lightweight, no external dependencies
  • Available as a browser extension for Chrome and Firefox