A Nano ID is a 21-character random string built from a fixed 64-symbol alphabet of uppercase and lowercase letters, digits, underscore, and hyphen, and it carries 126 bits of entropy by default. Generating one means producing a string of that shape locally with cryptographic randomness, which is why the request to "generate nanoid" is a routine part of building URL-friendly identifiers. The 21-character default is set by the official Nano ID project; each character contributes six bits because the 64-symbol alphabet fits exactly inside six binary digits, so the default space sits well above 10 to the 37th power. To produce a batch you pick a length between 1 and 128 and a quantity between 1 and 100, the browser draws bytes from window.crypto.getRandomValues, and rejection sampling maps those bytes onto the alphabet without favoring any symbol. The result is a newline-delimited list of strings that you can paste into code, a database seed, or a configuration file. Every operation stays inside the current tab, so no identifier, count, length, clipboard value, random byte, or usage event leaves the page.
Anatomy of a Nano ID string
The Nano ID specification, maintained in the official repository, fixes an alphabet of 64 printable ASCII characters and a default length of 21. That combination was chosen because each index fits in six bits, so the alphabet maps cleanly onto random byte ranges and the default carries 126 bits of entropy. The alphabet deliberately avoids slash, plus, equals, whitespace, and other characters that often need percent-encoding inside a URL path or query string. A Nano ID is not a UUID and does not claim RFC 4122 compatibility; it is its own compact format with its own collision math. It does not embed a timestamp, a counter, a region code, or a record type, so you cannot sort by creation time or infer business meaning from the characters themselves.
Two practical consequences follow from that design. First, Nano IDs fit comfortably in places where UUIDs feel bulky: short URLs, public-facing share tokens, and log lines that already carry timestamp prefixes. Second, because there is no embedded ordering, two IDs generated a millisecond apart cannot be compared lexicographically to know which came first. If your application needs offline chronological ordering or a parseable timestamp, a time-aware format like ULID or a UUID v7 is a better fit, because Nano IDs were never designed to carry that information.
How to generate a Nano ID batch
Open the Nano ID Generator in your browser and follow the same three steps that the tool enforces internally.
- Choose an ID length from 1 to 128 and a quantity from 1 to 100. The default length of 21 matches the official Nano ID API and is the safest starting point unless you have a measured reason to deviate.
- Generate the batch. The tool pulls bytes from window.crypto.getRandomValues, applies rejection sampling against a computed bit mask, and assembles each string from the official 64-symbol alphabet.
- Copy the newline-delimited IDs and paste them wherever they belong, then enforce uniqueness again in your durable data store rather than trusting the generator alone.
If the batch contains a duplicate, which is statistically unlikely but possible, the tool reports an error instead of silently returning the colliding string. That safeguard is local to the batch; it does not coordinate with IDs generated in other tabs, devices, processes, deployments, or earlier sessions, which is why the third step points back at the database rather than the page.
How Web Crypto and rejection sampling shape the output
The character distribution of a Nano ID is only as good as the random source feeding it. The Nano ID Generator uses the W3C Web Cryptography API primitive window.crypto.getRandomValues, which is the browser-blessed source for cryptographically strong random bytes. It does not call Math.random, derive values from timestamps, counters, browser fingerprints, or a deterministic seed. That distinction matters when identifiers must be difficult to predict, but it still does not turn an identifier into authentication, authorization, encryption, or a secret-management system; access control must remain independent of whether the ID looks random.
Pulling bytes is only half the problem. The other half is mapping those bytes onto the 64-symbol alphabet without bias. Naive code takes a random byte modulo the alphabet length, but that introduces a non-uniform distribution whenever the byte range is not evenly divisible by the alphabet size. The official Nano ID algorithm avoids this with rejection sampling: it computes a bit mask that covers exactly the values inside the alphabet range, draws bytes until each index falls inside that range, and discards the rest. Because the default alphabet has exactly 64 symbols and its indices fit in six bits, the mask aligns with whole bytes and rejection is rare in practice. Tests lock representative alphabet indices and every size and quantity bound so the implementation cannot drift.
Picking a length and what it costs
Length controls the size of the identifier's random space. With a 64-symbol alphabet, each character represents six bits, so the available space grows exponentially as length increases. Shortening the default trades entropy for a shorter string, and the cost is exponential. The table below summarizes the relationship between length, total bits, and the rough scale of the resulting space.
| Length | Entropy (bits) | Approximate space |
|---|---|---|
| 10 | 60 | ~1.15 × 1018 |
| 16 | 96 | ~7.92 × 1028 |
| 21 (default) | 126 | ~8.51 × 1037 |
| 32 | 192 | ~6.28 × 1057 |
| 64 | 384 | ~3.94 × 10115 |
These figures assume uniform symbol selection, and rejection sampling is what makes that assumption hold. The right length for your project depends on expected issuance volume, acceptable collision risk, retry behavior, storage lifetime, and how adversarial the exposure surface is. A public-facing share link that lives forever needs more entropy than an internal row identifier that gets a unique constraint and a retry loop. The page does not promise that any chosen length is collision-free, because no finite-length random identifier is.
Integrating the generated IDs into a real application
Paste the batch into your codebase the same way you would any other opaque identifier, then add the safety net the generator cannot provide on its own. The simplest reliable pattern looks like this.
- Retain the 21-character default unless a measured requirement justifies a different length; shorter is rarely safer, and shorter-than-default IDs grow the collision probability as the collection grows.
- Store the value in a column that preserves case and both punctuation characters. A case-insensitive collation will silently collide two distinct IDs that differ only in capitalization, and a column that strips hyphens or underscores will corrupt the alphabet.
- Add a unique constraint at the database level. Treat that constraint as the final authority on uniqueness rather than any check the generator performs inside the page.
- Retry only the failed insert, atomically, rather than checking first and writing later. The check-then-write pattern races against concurrent inserts and is how duplicates sneak into production.
- Test every route, log processor, analytics pipeline, CSV export, and database collation that handles the ID, because each one is a chance to truncate, lowercase, or strip a punctuation character.
These are the same recommendations that keep UUIDs healthy in production. Nano IDs are short, but the operational discipline around them is identical to any opaque identifier, and the short string length makes careless logging or transport handling more visible because the failure leaves obvious gaps in the alphabet.
The Nano ID Generator stays client-side by design, which makes it convenient for code that lives behind a strict data-residency boundary. Browser extensions, compromised scripts, and a compromised device can still observe page data, so do not generate passwords, API keys, recovery codes, signing material, or other high-value secrets here. Use the target platform's dedicated credential generator and secret manager for those jobs and reserve this tool for the IDs it was built to produce.