NanoID Generator

Real-world use cases

• Generate short public IDs for URLs instead of leaking auto-increment integers

  Exposing `/orders/1042` tells a competitor you have roughly a thousand orders and lets anyone walk `/orders/1043`, `/orders/1044`. Workflow: keep the integer primary key internal, add a `public_id` column, default it to a NanoID. Set the alphabet to URL-safe and the length to 12 (about 72 bits, more than enough for a per-table public handle). Generate a batch here, paste them into a seed migration, and your URLs become `/orders/V1StGXR8_Z5j` — unguessable and short enough to fit in a tweet. The collision readout confirms 12 chars survives billions of rows before the 1% mark.

• Create database primary keys that beat UUID v4 on index bloat

  UUID v4 is 36 characters and randomly distributed, which fragments a B-tree index. A 21-char URL-safe NanoID carries 126 bits of entropy — effectively the same uniqueness guarantee as a UUID's 122 — in 15 fewer bytes per row. Pick the URL-safe preset, leave length at 21, generate a sample, and verify the keyspace and "IDs until 1% collision" numbers against your projected write volume before you standardise on it. For append-friendly ordering you still want UUID v7, but for opaque keys NanoID is leaner.

• Build human-readable coupon or invite codes with a no-confusion alphabet

  A coupon code printed on a receipt gets typed back by a tired human, so `O` vs `0` and `l` vs `1` matter. Switch to the custom alphabet and paste `ABCDEFGHJKLMNPQRSTUVWXYZ23456789` (no O/0/I/1). Set length to 8 and generate 500 at once. The effective-size readout shows 32 characters, and the collision panel tells you 8 chars gives a ~40-bit keyspace — plenty for a few hundred thousand codes, and the math is right there so you do not over- or under-shoot the length.

• Seed test fixtures and mock data with deterministic-length IDs

  When you snapshot-test an API response, random UUIDs make the snapshot churn on every run. Generate a fixed batch of NanoIDs once, paste them into your fixtures file, and your snapshots stay stable. Use the numbers preset if your downstream parser is integer-ish, or hex if you are matching a `[0-9a-f]+` regex. Download the batch as a .txt and pipe it into your seed script.

• Generate device or session tokens that fit a fixed-width column

  IoT firmware and embedded logs often have a fixed-width identifier field — say exactly 16 characters. NanoID lets you nail the length precisely, unlike UUID's mandatory 32 hex digits + 4 hyphens. Set length to 16, URL-safe alphabet, copy a batch, and every token fits the column with 96 bits of entropy. The rate field lets you model "10,000 devices provisioning per second" and see when a collision becomes statistically plausible.

Common pitfalls

• Using `Math.random()` to roll your own NanoID. It is not cryptographically secure and is biased — attackers can predict the sequence, and some characters appear more often. This tool uses `crypto.getRandomValues` exclusively. If you copy the algorithm, copy the masking + rejection-sampling step too, not just the byte source.

• Taking `randomByte % alphabet.length` to map bytes to characters. Modulo skews the distribution toward the first `256 % length` characters whenever the alphabet size is not a power of two. The correct approach (used here) is a bitmask plus discarding out-of-range values, so every character is equally likely.

• Shrinking the length to make IDs prettier without checking the collision panel. Dropping from 21 to 6 characters with a 64-char alphabet cuts the keyspace from 10^37 to about 10^10 — a few hundred thousand IDs and you are already in collision territory. Read the 'IDs until 1% collision' number against your real volume before you trim.

Privacy