Your data is never sent to a server or stored anywhere. All processing happens in your browser.

ULID / NanoID / Snowflake Generator

Format

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.