The Nano ID Generator is a browser-based tool that creates cryptographically random, URL-friendly identifiers in batches of 1 to 100 strings with lengths from 1 to 128 characters, all computed locally using the Web Crypto API and Nano ID's official 64-symbol alphabet.
When you open the Nano ID Generator and click Generate, the page calls window.crypto.getRandomValues, draws rejection-sampled symbols, and shows a unique newline-delimited list — nothing is uploaded. The default output is 21 characters long, matching the Nano ID project's standard API. That default gives a random space large enough for ordinary application identifiers while staying short enough to drop directly into a URL path, a database key column, or a filename.
This article walks through exactly how to use the tool, what its controls mean, how to store the output safely, and where its scope ends.
What a Nano ID Is and Why It Works in URLs
A Nano ID is a fixed-length string drawn from a 64-symbol alphabet: uppercase letters A–Z, lowercase letters a–z, digits 0–9, underscore, and hyphen. That alphabet deliberately avoids slash, plus, equals, whitespace, and other characters that often need percent-encoding in URLs. You can paste a Nano ID into a path segment, a query parameter, a header, or a fragment without escaping it, and most web frameworks, logging pipelines, and CSV exports will keep the value intact.
Because the alphabet has exactly 64 symbols, each character fits in six bits (since 2^6 = 64). A 21-character ID therefore encodes 21 × 6 = 126 bits of randomness from a cryptographic source. That figure matches the reference Nano ID default and is comparable to the random portion of a UUID v4 (122 bits), but it uses fewer characters and a URL-safe alphabet.
Nano IDs are random. They do not encode creation time, region, shard, record type, or any business meaning. If you need chronological ordering, offline decoding of structure, or a standardized UUID representation, Nano ID is the wrong shape — pick ULID, UUID, or Snowflake instead.
Inside the Tool: Web Crypto and Rejection Sampling
Bias is the silent failure mode of any random-string generator built from scratch. If you take a random byte and compute byte mod alphabet.length, the symbol at the top of the alphabet appears slightly more often than the symbol at the bottom whenever the range of values is not evenly divisible by the alphabet size.
The Nano ID Generator follows the official library's rejection-sampling approach: it builds a bit mask, draws random bytes, ignores any value that falls outside the alphabet's index range, and keeps drawing until the requested length is filled. Because the alphabet has 64 entries and the mask is sized to fit, the test for "inside the alphabet" is exact and the resulting symbol distribution is uniform. The randomness comes from window.crypto.getRandomValues, the Web Crypto API primitive the W3C Web Cryptography specification defines for cryptographically strong bytes.
The page never calls Math.random, derives values from timestamps, counters, browser fingerprints, or a deterministic seed. It also does not transmit any identifier, length, count, or clipboard content to a server. Generation is entirely client-side, which means a compromised extension or a compromised device could still observe page data — a separate concern from server-side trust.
How to Use the Nano ID Generator
- Open the tool in your current tab and decide on a length between 1 and 128 characters. Leave the field at 21 unless a measured requirement justifies another value.
- Set the quantity between 1 and 100. The tool produces a batch, not a stream, so size the request to what you actually need rather than pulling the maximum every time.
- Click Generate. The page draws cryptographically random bytes through Web Crypto, applies rejection sampling against the 64-symbol alphabet, and assembles each ID to the requested length.
- Review the output for duplicates. If an extremely unlikely collision appears inside the same batch, the tool surfaces an error instead of silently returning the duplicate.
- Copy the newline-delimited list and paste it into your editor, terminal, or seed file.
- Insert each value into your database with a unique constraint, and let the durable store — not the browser — be the final authority on uniqueness.
The whole flow stays in the active tab. If you reload the page, the previous output is gone; if you need to recover IDs, paste them into a file before reloading.
Choosing a Safe Length for Your Identifier
Length controls the identifier's random space. Because the alphabet has 64 symbols, each additional character multiplies the space by 64, and each character contributes exactly six bits. Going from 10 to 21 characters enlarges the candidate space enormously, which is why the default 21-character value is widely considered safe for ordinary application use.
Shortening an ID is rarely free. A 10-character ID is fine for low-volume internal references; it is a poor choice for public-facing resource identifiers that an adversary can enumerate. Lengthening past 21 only helps when you have a specific threat model — for example, identifiers used in URLs that may be cached, logged, or scraped at internet scale.
The tool does not promise that any chosen length is collision-free, because no fixed-length random identifier can be collision-free in principle. Decide based on expected issuance volume, acceptable risk, retry behavior, storage lifetime, and adversarial exposure.
Pairing the Output With Your Database
The browser can guarantee uniqueness only within a single batch. It cannot coordinate with IDs created in another tab, another device, another process, or an earlier session, so the database must close that gap. Three practical rules follow.
First, store the ID in a column that preserves case and both punctuation characters. Default UTF-8 collations handle A–Z, a–z, 0–9, underscore, and hyphen without modification, but a case-insensitive collation will silently collapse different IDs together and break uniqueness.
Second, add a unique constraint to the column. Do not rely on application-layer "check then insert" logic, which is subject to race conditions when two requests arrive between the check and the insert. Let the durable store reject the second write.
Third, retry only the failed creation transaction when a constraint violation occurs. Returning a fresh batch and asking the user to pick another row is unnecessary and confusing — a single rerun with one new ID resolves the conflict.
| Format | Default length | Random bits | Alphabet | Encodes structure |
|---|---|---|---|---|
| Nano ID | 21 characters | 126 | 64 URL-safe symbols | No |
| UUID v4 (RFC 4122) | 36 characters (32 hex + 4 dashes) | 122 | Hex with dashes | Version and variant bits |
| ULID | 26 characters | 80 random + 48 timestamp | Crockford base32 | Yes, ms timestamp prefix |
For most database key use cases, Nano ID's shorter length wins on storage and index size; ULID wins when you need monotonic, time-ordered identifiers; UUID v4 wins when interoperability with systems that already expect the RFC 4122 format is required.
Limits of a Random Identifier You Should Respect
Random identifiers are not credentials. The Nano ID Generator is appropriate for primary keys, request IDs, share tokens, and short-lived resource locators; it is not appropriate for passwords, API keys, recovery codes, signing material, or any secret whose lifecycle must include rotation, revocation, and audited access. Use the target platform's dedicated credential generator and secure storage for those jobs, and never paste secret material into a browser tool — even a private one.
Random identifiers are also not access control. A URL that contains an unguessable Nano ID still has to be gated by authentication and authorization on the server side; the difficulty of guessing the ID is not a substitute for permission checks. The official Nano ID repository documents the algorithm; the companion guide on this site covers the local-generation path in more depth.
Test every route, log processor, analytics pipeline, CSV export, and database collation that handles the ID before shipping. A surprising number of systems trim whitespace, fold case, or strip punctuation by default. The right length and the right alphabet only matter if the storage stack preserves them.