How do you use this tool?
- Pick a use-case recipe at the top — or set length and alphabet manually.
- Choose the count: 1 for a single ID, 10/100/1 000/10 000 for bulk generation.
- Click "Generate" — the ID appears immediately. Copy to clipboard or download as CSV.
- Open the collision accordion and pick your expected volume — the probability of a collision is computed live via the Birthday Paradox.
- For codes that will be spoken or printed, pick the "No lookalikes" alphabet — the read-aloud badge confirms the choice.
What is a Nano-ID?
A Nano-ID is a compact, URL-friendly identifier — the shorter alternative to the classic UUID. Default is 21 characters from the URL-safe alphabet A–Z a–z 0–9 _ - (the URL-unreserved character set per RFC 3986). With 64 possible characters per position, 21 characters yield around 126 bits of entropy — comparable to UUID v4 (122 bits) but 15 characters shorter and without dashes.
Three properties distinguish this tool from the competitors reviewed in research:
- Inline collision calculator: while you pick length and alphabet, the built-in accordion shows live, via the Birthday Paradox, how likely a collision becomes at 1 000 / 100 000 / 1 M / 1 B / 1 T drawn IDs. Competing tools ship either a pure generator (no math) or a pure calculator (no generator) — we combine both.
- Use-case recipes: five 1-click presets for URL slug, API key, coupon code, session ID, and file suffix. Each recipe pins length AND alphabet to the canonical choice for that use case — no more “what length do I need?” paralysis.
- No-lookalike mode + read-aloud badge: the special alphabet without 0/O/o/1/l/I suits printed or spoken codes (coupons, OCR receipts, support tickets). A badge confirms ‘read-aloud friendliness’ instantly.
The UI follows Refined Minimalism: crypto badge at the top, five use-case recipes as cards, length and count side-by-side, alphabet dropdown, large ‘Generate’ button, output in monospace, collision accordion. No tracking, no account, no server.
How does the cryptographic random source work?
The tool uses crypto.getRandomValues() — the W3C Web Crypto API shipped in every modern browser since 2014. It returns unpredictable bytes from the operating system entropy pool: Linux uses /dev/urandom, macOS uses a similar random service, Windows uses its system crypto API. These sources are continuously fed from hardware events (keystroke timing, mouse movement, network jitter, disk latency).
From the 32-bit raw value, rejection sampling maps to an index into the chosen alphabet — without the modulo bias that byte % alphabetSize introduces for alphabet sizes that aren’t powers of two. This is the same algorithm the original Nano-ID library uses: mask with the smallest 2^k − 1 ≥ alphabetSize − 1, reject values ≥ alphabetSize, draw a new byte.
The browser-crypto badge at the top shows the active source. ‘Browser-crypto · cryptographic quality’ when crypto.getRandomValues() is available, ‘Pseudo-random · math-based’ in the rare fallback (very old browsers, exotic embedded WebViews). The RNG quality stays visible — competitor tools don’t do this.
How does the collision calculator compute probability?
The calculator uses the closed-form Birthday Paradox approximation:
P(collision) ≈ 1 − exp( −n·(n−1) / (2 · S) )with n = number of drawn IDs and S = alphabet size raised to length. The computation runs in log-space, so even n = 10^12 doesn’t overflow.
A few orders of magnitude for intuition:
| Length | Alphabet | Drawn IDs | Collision probability |
|---|---|---|---|
| 8 | 64 (URL-safe) | 1 M | ≈ 0.18 % |
| 8 | 36 (lowercase alphanum) | 1 M | ≈ 18 % |
| 8 | 56 (no lookalikes) | 1 M | ≈ 0.55 % |
| 12 | 64 (URL-safe) | 1 B | ≈ 7 × 10^-6 |
| 16 | 64 (URL-safe) | 1 T | ≈ 5 × 10^-9 |
| 21 | 64 (URL-safe) | 1 T | ≈ 3 × 10^-15 |
| 32 | 64 (URL-safe) | 1 T | < 10^-37 |
Rule of thumb: at short lengths (≤12 characters) you MUST know your volume; at 21 characters a collision is practically impossible even at 1 trillion drawn IDs. The calculator shows five qualitative tiers — ‘Practically impossible’, ‘Very rare’, ‘Rare’, ‘Possible’, ‘Likely’ — with a color-coded badge so you can tell at a glance whether your choice holds up.
Which use-case recipes are included?
Five presets cover the most common scenarios — each one pins both length AND alphabet on a single click:
URL slug (8 characters, URL-safe). Ideal as a short identifier inside URLs, hand-readable and encoding-free. Example: example.com/p/aB3xK_7q. Search space 64^8 ≈ 2.8 × 10^14 — plenty for any link shortener and for Pastebin-style apps up to about 100 million entries. For high-volume URLs (>1 B) prefer 10–12 characters.
API key (32 characters, alphanumeric, no symbols). Without _ and - for maximum compatibility with token headers and tools that occasionally interpret symbols as separators. Search space 62^32 ≈ 2.3 × 10^57 — collision-mathematically untouchable at any realistic volume.
Coupon code (8 characters, no lookalikes). Designed for printed codes on receipts or postal mailers. Removes 0/O/o/1/l/I — 56 characters remain, search space 56^8 ≈ 9.7 × 10^13. Up to 1 million codes the collision probability stays around 0.55 %, which is uncritical for coupon runs (duplicates are caught at the POS).
Session ID (21 characters, URL-safe). The Nano-ID standard default — the safest one-size-fits-all value. Search space 64^21 ≈ 4 × 10^37, equivalent in entropy to a UUID. Safe for web sessions, persistent user IDs, and cookie values. Also a clean drop-in replacement for UUID v4 when URL length matters.
File suffix (6 characters, lowercase + digits). For temporary filenames like report-x7k2qm.pdf or upload hashes. Lowercase matches most filesystem conventions (Windows is case-insensitive, Linux case-sensitive — lowercase avoids both traps). Search space 36^6 ≈ 2.2 × 10^9 — safe up to 10 000 parallel uploads per user.
What does the tool deliberately not do?
Three things the tool stays out of on purpose:
- No UUID generation: that lives in the separate UUID generator — clean separation prevents UI bloat. If you need UUID v4 or v7, the sibling tool is the right place.
- No sequential IDs (ULID, KSUID, Snowflake): those are time-based identifiers with different properties (lexicographic sort order, embedded timestamp). If demand surfaces, they’ll get a dedicated sibling tool — until then a deliberate gap.
- No streaming for >10 000 IDs: anything bigger would block the main thread. 10 000 is the sweet spot between ‘useful for CSV import generation’ and ‘stays responsive in the UI’. For genuine high-volume needs, use a server-side library.
Statistically, crypto.getRandomValues() is auditably uniformly distributed for all standard use cases. Browser vendors test the implementation against the NIST SP 800-22 test suite — 16 statistical hypothesis tests that every modern JavaScript engine passes.
For applications that demand true physical randomness — cryptographic key generation for high-security systems, scientific studies with double-blind randomization — a hardware RNG is the reference. Browser crypto covers 99 % of realistic ID use cases, but it is explicitly not a hardware random source.
Last updated: