Dev
Fake Snowflake ID Generator
Testing distributed systems with auto-incremented integers instead of Snowflake IDs hides real bugs. Cursor-based pagination breaks when IDs are not time-sortable. Shard routing logic is never exercised. 64-bit integer overflow silently truncates in JavaScript. This generator produces structurally correct 64-bit Snowflake IDs that expose all three categories of issue. Each ID packs a millisecond-precision timestamp into bits 63–22, your datacenter ID (0–31) into bits 21–17, your worker ID (0–31) into bits 16–12, and a 12-bit sequence into bits 11–0. Generated IDs are built from recent timestamps offset by up to 30 days, so they land in a plausible time range without clustering at a single millisecond. Set worker ID and datacenter ID to match your actual deployment topology and the generated IDs behave exactly like production values from that node — correct namespace, correct sort order, correct bit layout. Set the count to generate a batch for fixture files or seed scripts. Because IDs are derived from real timestamp arithmetic using BigInt, the output is safe to parse as a string in JavaScript without precision loss.
How to use
- Choose your options above
- Click Generate
- Copy your result
Detailed instructions
- Set 'How Many' to the number of Snowflake IDs your test fixture or database seed script requires.
- Enter the Worker ID (0–31) that matches the specific node or process you are simulating in your system.
- Enter the Datacenter ID (0–31) that corresponds to the deployment region or cluster you are testing against.
- Click Generate to produce the batch of Snowflake IDs in the output list.
- Copy the IDs directly into your seed file, fixture JSON, or test setup code, treating them as strings if your language is JavaScript.
Use Cases
- •Seeding a Postgres staging database with time-sortable 64-bit primary keys before a load test
- •Building Jest or Cypress fixtures with plausible Discord message IDs for API integration tests
- •Populating cursor-based pagination tests in Postman where chronological ID order must hold
- •Verifying that an ORM correctly handles 64-bit integer keys without silent overflow or truncation
- •Reproducing a specific worker and datacenter namespace to isolate a shard routing regression
Tips
- →Use different worker/datacenter combinations across test suites to confirm your code handles IDs from multiple nodes without collisions.
- →Generate IDs in multiple small batches with different worker IDs, then merge and sort them to stress-test cursor-based pagination across shards.
- →If your ORM stores IDs as 64-bit integers, verify the column type is BIGINT, not INT — Snowflake IDs exceed the 32-bit integer max of 2,147,483,647.
- →When mocking Discord API responses, use Discord's epoch (Jan 1, 2015) as context; IDs generated here will look plausible in timeline order for recent dates.
- →For load testing, generate a large batch once, store it in a fixture file, and reuse it — this keeps test runs deterministic and avoids timestamp drift between runs.
- →Always store Snowflake IDs as strings in JSON payloads and JavaScript variables to avoid silent precision loss above 2^53.
FAQ
how do snowflake IDs encode time and why does sort order matter
The timestamp occupies the 41 most significant bits, so sorting IDs numerically gives the same order as sorting by creation time. This is critical for cursor-based pagination: you can resume a query from the last seen ID without storing a separate timestamp column, and the sort runs on a standard integer index.
will fake snowflake IDs collide with real production IDs
Collision is theoretically possible but negligible in isolated test environments. Generated IDs are built from real current timestamps plus your chosen worker and datacenter values, so overlap with a production ID requires the exact same millisecond on the same worker node. Never insert generated IDs directly into a live production database.
do javascript and python handle 64-bit snowflake IDs safely
JavaScript's Number type safely represents integers only up to 2^53, so large Snowflake IDs lose precision when parsed as plain JSON numbers — always use strings or BigInt. Python integers are arbitrary precision, so no special handling is needed. This is why Discord and Twitter return Snowflake IDs as strings by default, a pattern worth copying in your own mock fixtures.
what do the worker ID and datacenter ID fields control
Worker ID (0–31) and datacenter ID (0–31) occupy bits 12–16 and 17–21 of the 64-bit ID respectively. Setting them to match your actual deployment means generated IDs fall in the same namespace as production IDs from that node, which is useful for reproducing shard routing bugs or testing ID partitioning logic against specific node configurations.
You might also like
Popular tools from other categories that share themes with this one.
Try these next
More free tools from other corners of the catalog, picked by shared themes.