A Nano ID generated online here is a URL-safe random string of 1 to 128 characters, drawn from the official 64-symbol Nano ID alphabet with the browser's cryptographic random source and never sent to a server.
The phrase "nano id online" covers two related needs: producing an identifier on demand, and knowing where the value came from. The Nano ID Generator handles both on a single page. You set a length and a quantity, generate a batch, and copy newline-delimited IDs that stay in the current tab. What it does not do is turn an identifier into authentication, a credential, or a secret.
What the Generator Sets and Returns
Every control on the page maps to a fixed set of choices, so you can predict the shape of the output before generating anything.
| Control or output | Supported value | Why it matters |
|---|---|---|
| ID length | 1 to 128 characters (default 21) | The default matches the length the official Nano ID API returns |
| Batch quantity | 1 to 100 IDs | Enough for a seed batch, a fixture set, or a migration run |
| Alphabet | 64 symbols: uppercase letters, lowercase letters, digits, underscore, hyphen | No slash, plus, equals, or whitespace, so IDs survive a URL unchanged |
| Random source | window.crypto.getRandomValues | Cryptographically strong bytes, per the W3C Web Cryptography API |
| Output | Newline-delimited text, one ID per line | Ready to paste into a script, a fixture file, or an import |
| Duplicate handling | Batch-level check before display | A duplicate inside one batch raises an error instead of being returned silently |
The alphabet is the same 64-symbol set used by the official Nano ID project: uppercase letters, lowercase letters, digits, underscore, and hyphen. Because that set avoids slash, plus, equals, and whitespace, an ID can sit in a path segment or a query parameter without escaping. The default length of 21 characters matches the length the project's normal API returns.
Generation and copying are client-only. No identifier, count, length, clipboard content, random byte, or usage event is sent to a server, and every result stays in the current tab until you copy it or close the page.
Generating a Batch in Three Steps
- Open the Nano ID Generator and set the ID length between 1 and 128 characters, then set the quantity between 1 and 100. Keep the 21-character default unless you have a measured reason to move away from it.
- Generate the batch. The tool draws random bytes from window.crypto.getRandomValues, maps them onto the 64-symbol alphabet with Nano ID's rejection-sampling method, and checks the finished batch for duplicate values before displaying it.
- Copy the newline-delimited IDs and enforce uniqueness again in your durable data store: add a unique constraint on the ID column, handle the conflict atomically, and retry only the failed creation transaction.
Those three steps are the complete workflow. There is no account to create, no configuration file to maintain, and no server round trip between choosing a length and holding a finished ID.
Where the Randomness Comes From
The generator does not call Math.random, and it does not derive values from timestamps, counters, browser fingerprints, or a deterministic seed. A predictable identifier is not much of an identifier: if an observer can replay the sequence, they can guess what comes next, which defeats the point of a random public handle.
Mapping random bytes onto characters carries a subtler trap. Taking a random byte modulo the alphabet size biases the result whenever the byte range is not evenly divisible by the alphabet size, and the favoured symbols then appear more often than the rest. This implementation follows Nano ID's rejection-sampling approach instead: it builds a bit mask, discards masked values that fall outside the alphabet, and keeps drawing until the requested length is complete. The W3C Web Cryptography API is the specification behind the random primitive, and the same browser-side method is walked through in Generate Nano IDs Locally With Web Crypto Randomness.
One calculation shows the size of the default space:
- The alphabet holds 64 symbols, and 64 equals 2 to the 6th power, so each character carries 6 random bits.
- The default length is 21 characters.
- 21 characters multiplied by 6 bits per character gives 126 bits of randomness in the default value.
That 126-bit figure describes the identifier's random space before any application behavior, and it is not a promise of collision-free output. It also says nothing about whether the value belongs in a password field. The official project remains the authority on ecosystem compatibility, so treat this page as a convenient generator rather than a change to the library's semantics.
Choosing a Length and a Format That Fit
Shortening an ID cuts the available space exponentially and raises collision probability as the collection grows. No length is collision-free, and the page makes no such claim. Before moving off the 21-character default, weigh the expected issuance volume, the collision risk you are willing to accept, your retry behavior, how long records live in storage, and whether the identifiers are exposed to an adversary.
Format matters as much as length, because a Nano ID carries no structure beyond randomness.
| Format | What it encodes | Ordering | Where it fits |
|---|---|---|---|
| Nano ID | Randomness only | None | Compact public identifiers in URLs, filenames, and records |
| UUID version 4 | Randomness in a fixed textual format | None | Systems that require a standardized UUID representation |
| ULID | Randomness plus an embedded timestamp | Lexicographic time ordering | Databases that need sortable creation order |
| Timestamp or counter value | Time or sequence | Chronological by construction | Legacy sequences where predictability is acceptable |
Exact random-space figures for each format come from that format's own tooling; the figures on this page apply only to Nano ID. If your stack requires a standardized UUID representation, the UUID Generator creates RFC 4122 version 4 values in the browser. If records need to sort by creation time, the ULID Generator produces sortable identifiers and can decode the embedded millisecond timestamp.
Do not infer chronology or business meaning from random characters. Nano ID strings are not sequential and do not encode time, region, shard, record type, or creation order, so a system that needs lexicographic time ordering, offline decoding, or a standardized UUID representation should pick a format designed for that purpose.
Where the Duplicate Check Stops
Each generated batch is checked for duplicates before it is displayed, and if a duplicate appears inside that batch, the tool reports an error rather than quietly returning it. At length 1, only 64 distinct IDs are possible, so a quantity of 65 to 100 necessarily contains a duplicate and causes the batch to error; use a quantity of 64 or less for that length. That check is local to the batch you just generated. It does not coordinate with IDs produced in other tabs, on other devices, in other processes, in other deployments, or during earlier sessions.
That boundary is why the durable store has to be the final authority. Checking first and inserting later leaves a window in which two concurrent writers can both pass the check, so put a unique constraint on the ID column and make creation atomic: attempt the insert, and when the database reports a conflict, retry only that failed creation transaction rather than the whole batch. With a properly constrained table, a duplicate attempt is cheap to detect and trivial to retry.
What This Tool Must Not Be Used For
A random identifier is not a credential. The generator provides no authentication, no authorization, no encryption, and no secret management, and access control has to remain independent of whether an ID looks random. Do not generate passwords, API keys, recovery codes, signing material, or other high-value secrets here. Browser extensions, compromised scripts, and a compromised device can still observe page data, so use the target platform's dedicated credential generator and secure storage for those jobs. The privacy details and threat model are covered in Is a Nano ID Generator Safe to Use Online?.
Client-side generation removes the server as a place where your identifiers are logged or stored, but it does not remove the browser from the trust boundary.
Testing the Path an ID Actually Takes
Identifiers rarely travel a single route, so exercise each one before you rely on it. Store the value in a column that preserves case and both punctuation characters, underscore and hyphen, because a collation or storage setting that folds case or drops characters can quietly alter an ID on the way in. Add the unique constraint, and test every route, log processor, analytics system, CSV export, and database collation that handles the ID. A log line that truncates a long value, an export that re-quotes it, or a case-insensitive collation that treats two distinct IDs as equal will all surface later as mismatches that are hard to trace back.
Keep the 21-character default unless a measured requirement justifies another length, confirm that your schema preserves the exact string, and let the database handle conflicts. That combination keeps the random space large, keeps the value reproducible from the string alone, and keeps the uniqueness decision where every concurrent writer can see it.