ULID / NanoID / Snowflake Generator
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
How to Use
Pick a format (ULID, NanoID, or Snowflake) and the number of IDs to generate. IDs are regenerated automatically when you change settings. Click an ID or the copy button to copy it.
Which Format Should I Use?
Each format trades off readability, sortability, and length. Pick the one that fits your storage and ordering needs:
- ULID (26 chars, Crockford Base32): Sortable by creation time. Case-insensitive alphabet without I/L/O/U. Good when you want UUID-level uniqueness plus time ordering, with a more readable alphabet.
- NanoID (21 chars, URL-safe): Pure random, URL-safe alphabet (A-Z a-z 0-9 _ -). Shorter than UUID with similar collision odds. Good for short tokens, share links, and external-facing IDs.
- Snowflake (64-bit integer): Twitter-style numeric ID with embedded millisecond timestamp. Sortable, fits in a BIGINT column. Useful when you want time-sortable numeric primary keys.
All three are generated entirely in the browser using crypto.getRandomValues(). The Snowflake worker ID is randomized per-call, so it is suitable for client-side use but does not match the strict server-coordinated guarantees of the original Twitter implementation.
Format Specifics
Each generator follows the published spec for its format:
- ULID: 48-bit millisecond timestamp + 80-bit randomness, Crockford Base32-encoded. Per the ulid/spec project.
- NanoID: 21 characters from a 64-character URL-safe alphabet. Modulo bias is avoided because 256 / 64 = 4 exactly — every alphabet character has equal probability per byte.
- Snowflake: 41-bit milliseconds since the Twitter epoch (2010-11-04T01:42:54.657Z) + 10-bit worker ID + 12-bit sequence. Both worker ID and sequence are randomized per generation.
Privacy & Security
All generation happens in your browser using crypto.getRandomValues(). No data is sent to any server.
FAQ
How do I choose between ULID, NanoID, and Snowflake?
ULID is time-sortable with UUID-level uniqueness, making it good for database primary keys. NanoID is a short, URL-safe random ID suited to tokens and share links. Snowflake is a 64-bit integer with an embedded timestamp, ideal when you want a numeric primary key that fits in a BIGINT column.
Are the generated IDs sent to a server?
No. All ID generation runs locally using the browser's standard crypto.getRandomValues(), and neither the results nor any seed values are ever sent to a server.
How many IDs can I generate at once?
You can specify a count to generate several IDs at once, and they regenerate automatically when you change settings. The tool handles practical batch sizes up to your browser's memory limits.
Is this Snowflake the same as Twitter's implementation?
It follows the spec (41-bit milliseconds + 10-bit worker ID + 12-bit sequence, using the Twitter epoch of 2010-11-04), but the worker ID is randomized per call. It does not provide the strict server-coordinated uniqueness guarantees, so it is intended for client-side use.
Why is a ULID sortable by time?
A ULID stores the millisecond timestamp of creation in its leading 48 bits, encoded with Crockford Base32. As a result, sorting the strings lexicographically orders them almost exactly by creation time.