Generate Nanoid Online

How to Generate Nano IDs Online

1. Set the Size: Default is 21 characters — the same length the nanoid reference library ships with, which yields about 126 bits of entropy from the default 64-symbol URL-safe alphabet. Drop to 8–12 chars for short share codes (acceptable when the keyspace is scoped, e.g. per-user URLs); keep 21 for general-purpose primary keys; push to 32 or longer for high-volume distributed systems that mint billions per day.
2. Pick an Alphabet: The default A-Za-z0-9_- (64 symbols) is URL-safe by construction — no percent-encoding required in path segments or query strings. Switch to No-Lookalikes (49 symbols, drops 0, O, 1, l, I, u, v, 5, S and other confusable pairs) for codes humans type or read aloud; Numbers for OTP-style displays; Lowercase or Uppercase for case-sensitive systems; Alphanumeric (62 symbols) when underscores and hyphens are reserved characters in the consuming system. Or paste a custom alphabet up to 256 symbols for niche encodings.
3. Set Quantity: Generate a single ID for ad-hoc use or batch hundreds at once for database seeding, fixture files, or pre-allocated share codes. All IDs come from one crypto.getRandomValues() call, so batches return in microseconds even at the upper limit.
4. Generate and Copy: Click Generate. IDs appear in the output panel — copy a single value or select-all for the batch. Everything runs in your browser via the Web Crypto API; nothing is uploaded, logged, or stored.

Why Generate Nano IDs?

Nano ID is a URL-safe unique-string ID generator originally created by Andrey Sitnik for JavaScript in 2017 and now ported to 20+ languages. The spec — published at github.com/ai/nanoid — defines a 21-character default built from a 64-symbol alphabet (A-Za-z0-9_-) seeded by a cryptographically secure RNG. The result is roughly 126 bits of randomness in 21 characters, slightly more entropy than UUID v4's 122 bits but in 42% less string length (21 chars vs UUID's 36).

• Short, URL-safe primary keys — Postgres, MySQL, MongoDB, and SQLite all accept varchar/text PKs. A 21-char Nano ID stored as VARCHAR(21) takes 21 bytes vs UUID's 36-byte text form (or 16 bytes binary), and reads cleanly in URLs like /orders/V1StGXR8_Z5jdHi6B-myT without percent-encoding.
• Share links and short-URL slugs — Bitly, dub.co, and most URL shorteners use 6–8 character random tokens from a similar alphabet. Nano ID at length 8 gives ~48 bits of entropy — enough for tens of billions of unique tokens in a single namespace, with a generation rate that needs decades to hit a collision.
• Invite codes, recovery codes, and 2FA backup codes — Pair the No-Lookalikes preset with length 10–12 for codes that humans type from a printed slip or read aloud over the phone. The smaller alphabet trades two bits per character for typo resistance.
• Database fixture seeding and integration tests — Bulk-generate hundreds of IDs for test fixtures, mock data sets, k6/JMeter load tests, or anonymized exports. Each ID is independent, so tests can run in any order without cross-contamination.
• Object storage keys and uploaded-file names — S3, GCS, and Azure Blob keys with random prefixes spread writes across storage partitions. A Nano ID-prefixed key (<nanoid>/<filename>) avoids the hot-partition penalty that sequential keys incur.
• API request and correlation IDs — Stamp each incoming request with a Nano ID and propagate via X-Request-ID for log correlation. Shorter than a UUID means less log volume and faster grep over high-cardinality traces.

Nano ID vs UUID v4 vs ULID vs Short ID

Property	Nano ID (default)	UUID v4	ULID	Short ID (length 8)
Length	21 chars	36 chars (with hyphens)	26 chars	8 chars
Alphabet	64 (A-Za-z0-9_-)	16 (hex + hyphens)	32 (Crockford base32)	64 (URL-safe)
Random bits	~126	122	80 (+ 48-bit ms timestamp)	~48
URL-safe without encoding	Yes	Yes	Yes	Yes
Sortable by creation time	No	No	Yes (lexicographic)	No
Reveals creation time	No	No	Yes (48-bit ms prefix)	No
Reveals host MAC	No	No	No	No
Standardized in an RFC	No (de facto spec)	Yes — RFC 9562	No (Stripe-published spec)	No
Typical use	URL-friendly PKs, short links	Distributed PKs, request IDs	Sortable event IDs	Coupon codes, share IDs

Alphabet Presets and What They Buy You

Preset	Characters	Symbols	Bits per char	Best for
Default URL-safe	A-Za-z0-9_-	64	6.0	General-purpose IDs in URLs
Alphanumeric	A-Za-z0-9	62	5.95	Systems where _ or - are reserved
Lowercase	a-z	26	4.7	Case-insensitive storage / DNS labels
Uppercase	A-Z	26	4.7	Coupon codes, license-key blocks
Numbers	0-9	10	3.32	OTPs, PINs, numeric-only fields
Hex lowercase	0-9a-f	16	4.0	Legacy systems that expect hex
No-Lookalikes	drops 0OoIl1uv5S	49	5.61	Human-readable codes (typed, spoken)
Custom	up to 256	varies	log₂(N)	Domain-specific encodings

At length 21, the default alphabet gives ~126 random bits. Smaller alphabets reach the same bit count by adding characters: at 21 chars Numbers-only gives ~70 bits (good for OTPs, not PKs), so push to 38+ chars if you need UUID-equivalent collision resistance from digits alone.

Frequently Asked Questions

Why does Nano ID default to 21 characters?

21 characters of the 64-symbol URL-safe alphabet yield 21 × log₂(64) = 126 bits of randomness. That's slightly more than UUID v4's 122 random bits, so a 21-character Nano ID is at least as collision-resistant as a UUID while being 15 characters shorter. The Nano ID README states that to reach a one-in-a-billion chance of a single duplicate you'd need to generate 103 trillion IDs — practically unreachable for any single application.

How does Nano ID compare to UUID v4 in practice?

Same security class, smaller payload. Both use a cryptographically secure RNG (browser Web Crypto API or crypto.randomBytes() on Node); both have ~120 bits of entropy; both are URL-safe in the sense that they need no escaping in path segments. Differences: Nano ID is 21 chars vs UUID's 36, uses a 64-symbol alphabet vs UUID's 16-symbol hex-and-hyphens, and is not standardized in an IETF RFC (UUID is, via RFC 9562). Pick Nano ID when string length matters (URLs, log volume, varchar storage); pick UUID when you need cross-system interop with database uuid types, drivers, and existing tooling that expects the 36-character canonical form. See the UUID generator when you need the RFC-standardized format with built-in version controls.

What is the collision probability at the default 21-character length?

The Nano ID project documents that, with the default 21-character size and the 64-symbol alphabet, you would need to generate roughly 103 trillion IDs to reach a one-in-a-billion chance of a single collision. At one million IDs per second — well above what any single application produces — that's about 3,200 years to one-in-a-billion. Treat collisions as a physical-impossibility-class event, not something to defend against in application code.

Are these Nano IDs cryptographically random?

Yes. The generator pulls bytes from the browser's Web Crypto API crypto.getRandomValues(), which MDN documents as producing "cryptographically strong random values" seeded from a platform random source (/dev/urandom on Linux/macOS, BCryptGenRandom on Windows). This is the same primitive crypto.randomUUID() uses, the same class of source Node's crypto.randomBytes() and Python's secrets module use, and is safe for security tokens, password-reset links, OAuth state parameters, and CSRF tokens.

Why use the No-Lookalikes alphabet?

It removes characters that humans confuse when reading aloud or typing from a screenshot: 0/O/o, 1/l/I, and a handful of other visually similar pairs like 5/S and u/v. That leaves 49 symbols — about 5.6 bits per character vs the default's 6.0. To keep the same total entropy as a 21-character default ID, lengthen the No-Lookalikes output by 1–2 characters. Use it for any code a human will type from a printed receipt, read off a screen during onboarding, or speak over the phone to support.

Can I use Nano ID as a database primary key?

Yes, with a tradeoff to be aware of. Nano IDs are random (not time-ordered), so inserts land at random positions in a B-tree primary-key index, causing more page splits and cache misses than a sequential ID would. For tables under ~10M rows this overhead is invisible; at 100M+ rows on a write-heavy workload, a time-ordered ID like UUID v7 (via the UUID generator) will outperform Nano ID on insert throughput while keeping similar uniqueness properties — its 48-bit Unix-millisecond prefix makes inserts append to the B-tree tail instead of scattering. Use Nano ID PKs when URL appearance matters more than peak insert performance.

How do I use Nano ID in code?

In JavaScript: npm i nanoid, then import { nanoid } from 'nanoid' and call nanoid() for the default 21-char ID, or nanoid(10) for a custom length. For a custom alphabet: import { customAlphabet } from 'nanoid' then const id = customAlphabet('1234567890ABCDEF', 10). Nano ID v5 ships both ESM and CommonJS via package.json exports, after v4 was briefly ESM-only. The package is around 118 bytes minified-and-brotlied with zero dependencies — small enough that adding it to a browser bundle is essentially free. Ports exist for Python (pip install nanoid), Go, Rust, Java, PHP, Ruby, Swift, and 15+ other languages, all on the Nano ID GitHub page.

Where is the official Nano ID specification?

There is no IETF RFC for Nano ID — the canonical specification is the reference implementation at github.com/ai/nanoid and its README, maintained by Andrey Sitnik (Evil Martians). The spec covers the default alphabet (A-Za-z0-9_-), the default size (21), the requirement for a cryptographically secure RNG, and the bias-free generation algorithm (rejection sampling against the alphabet length so that every character is equally likely). All ports listed in the README follow the same alphabet, length, and bias-handling rules — a Nano ID generated by the Go port is indistinguishable from one generated by JavaScript.

How does Nano ID differ from a slug or a hash?

A slug is a human-readable URL fragment derived from a title ("My First Post" → my-first-post); it's not unique on its own. A hash is a deterministic function of input bytes — same input always yields the same output. A Nano ID is a random unique identifier — independent of any input and not reproducible. Use Nano IDs when you need a unique handle for a new object; use hashes when you need content-addressed names; use slugs when you want a human-readable URL fragment, often paired with a Nano ID for uniqueness (/posts/my-first-post-V1StGXR8). For unguessable secrets that humans type rather than systems consume, the password generator produces strings with the same RNG but with character-class controls geared to password-strength policies.