NanoID Generator

NanoID makes the identifier space configurable

Nano ID describes compact random string identifiers drawn from an alphabet. Unlike UUID, the visible value has no version nibble, variant field, fixed hyphen layout, or universal 128-bit serialization. Length and alphabet together define the number of possible strings. That flexibility is useful for URL slugs, local object IDs, coupon-like test data, and systems with character restrictions, but it also makes poor configurations easy to create.

This custom NanoID generator offers lengths from 1 to 128, counts from 1 to 100, an editable alphabet, six preset alphabets, individual and bulk copy, regeneration, estimated entropy, and a birthday-bound collision display. Controls regenerate output as they change. The standard-looking default is 21 characters drawn from a 64-character URL-safe alphabet.

The component uses window.crypto.getRandomValues() when available, but its exact generation method is not the official Nano ID library algorithm. It maps each random byte with byte % alphabet.length, which introduces modulo bias whenever the alphabet size does not divide 256. It also falls back to Math.random() if Web Crypto is unavailable. Therefore this page is suitable for development samples and configuration exploration, not as the authority for production identifiers or security tokens. Use the maintained nanoid package or a vetted rejection-sampling implementation in production.

Shape the alphabet deliberately

The Standard (URL-safe) preset uses 64 letters, digits, _, and -. Those characters travel cleanly in URL path segments without ordinary percent encoding. A 21-character value from 64 equally likely symbols represents 126 ideal bits because each symbol carries exactly 6 bits.

Other presets trade space for constraints:

• Lowercase Alphanumeric has 36 symbols and avoids case-sensitive storage issues.
• Uppercase Alphanumeric suits labels that conventionally capitalize.
• Numbers Only may fit numeric fields but needs substantially more length for comparable space.
• Hexadecimal has 16 symbols, exactly 4 ideal bits per character.
• Readable (No Lookalikes) removes confusing characters for human transcription.

You can type a custom alphabet directly. Repeated characters are especially dangerous here. The statistics card counts unique characters with a Set, but generation samples positions from the original string. In an alphabet AAAB, A occurs with probability 3/4 rather than 1/2, so the displayed unique-alphabet entropy overstates actual entropy. Deduplicate the alphabet before use. Also remember that JavaScript splits by UTF-16 code units; emoji and some non-BMP symbols may be split into surrogate halves, producing invalid output. Prefer distinct single-code-unit ASCII characters in this tool.

Case sensitivity, database collation, filesystem rules, and spoken readability can shrink the effective alphabet. If storage compares A and a as equal, a mixed-case ID space is smaller than the generator assumes and distinct outputs can conflict. Test the complete path, not just the browser display.

Length, entropy, and collision probability

For a uniform alphabet of size A and length L, the ideal space has A^L values and estimated entropy is:

H = L × log2(A)

A 16-character hexadecimal ID has 64 ideal bits. A 12-character lowercase-alphanumeric ID has about 12 × log2(36), or 62 bits. These calculations describe uniform selection and say nothing about secrecy once an ID is logged or shared.

Collisions follow the birthday effect. For probability p in a space of size N, an approximation for the number of generated IDs is:

n ≈ sqrt(2N × ln(1 / (1 - p)))

The card estimates time to a 1% chance while generating 1,000 IDs per second. It is a planning illustration, not a warranty. It assumes independent, uniform output and sustained rate, and it does not account for this component’s modulo bias, duplicate alphabet characters, fallback randomness, multiple systems sharing a namespace, or implementation defects. Work with the number of IDs expected over the system’s full lifetime, not only today’s request rate.

An identifier can have a comfortably low collision risk while being unsuitable as a secret. Enumeration resistance, offline guessing, authorization, expiration, and leakage channels are separate concerns.

Operate the page as a design worksheet

Select a preset close to the destination constraints, then set Length with either slider or numeric input. The numeric control clamps values to 1–128. Set Count to 1–100. Clicking Regenerate replaces the batch; clicking an item copies one value; Copy All writes newline-separated output.

For a development URL such as /draft/V1StGXR8_Z5jdHi6B-myT, standard URL-safe output avoids slash and plus characters. For a printed warehouse fixture, choose Readable and increase length to compensate for the smaller alphabet. For a hexadecimal schema test, choose Hexadecimal and ensure the database does not mistake the string for a number; leading zeroes are significant.

Do not use Numbers Only output as an OTP simply because it looks like one. OTP systems require a verification protocol, brief validity, attempt limits, and secure state. Similarly, a coupon code needs issuance records, redemption rules, anti-enumeration controls, and sometimes a check symbol for transcription errors. Random text alone supplies none of those workflows.

A production integration checklist

Define the alphabet and length as versioned constants shared by all generators. Use the official Nano ID implementation for the runtime and prohibit insecure fallback. Generate once when the logical entity is created, not each time a component renders or an HTTP request retries.

Store IDs as strings under a binary or case-sensitive collation compatible with the alphabet. Apply a unique constraint and retry on conflict. The probability may be tiny, but constraints also catch duplicate requests, seed failures, and coding errors. Avoid a pre-insert existence query as the sole defense because concurrent requests can race.

Test 100,000 or another practical sample for format and duplicates without claiming that the sample proves collision resistance. Assert exact length, membership in the declared alphabet, URL round trips, JSON serialization, database retrieval, and case behavior. Mock the random-byte provider for deterministic unit tests, then run integration tests with the real secure provider.

For idempotent APIs, decide who creates the ID. A client-generated object ID can support offline creation, while a separate idempotency key may control request replay. Preserve one key across retries. Never infer tenant ownership from an ID prefix or rely on obscurity; authorize every object lookup.

If IDs appear in URLs, consider logs, analytics, referrer headers, support screenshots, and search indexing. A public ID can remain stable, while password reset and invitation tokens should be separate secrets with expiry and one-time redemption. Store high-value tokens using an appropriate keyed or hashed verification design so a database leak does not immediately expose usable bearers.

Modulo bias in concrete terms

A byte has 256 possible values. With a 10-character alphabet, byte % 10 maps six characters from 26 byte values each and four characters from 25 values each. The difference is small per symbol but real. For a 64-character alphabet, 256 divides evenly and this particular mapping is unbiased. For 36 or many custom sizes, it is biased.

Rejection sampling solves this by discarding byte values above the largest evenly divisible range and drawing replacements. The official library also sizes masks and random buffers for efficient unbiased selection. Do not repair the page output by hashing it or shuffling afterward; use the correct generator at the source.

Mistakes seen in custom ID schemes

• Counting duplicate alphabet positions as if they were unique equiprobable symbols.
• Shortening IDs after launch without recalculating lifetime collision risk.
• Using a case-insensitive column for a mixed-case alphabet.
• Treating a random identifier as permission to read the referenced object.
• Using Math.random() when Web Crypto is missing rather than failing closed.
• Converting numeric-only IDs to numbers and losing leading zeroes.
• Assuming “NanoID” means every custom implementation matches the official package.

FAQ

What is the best NanoID length?

There is no universal length. Choose from alphabet size, projected lifetime count, acceptable collision probability, storage behavior, and whether the value needs guessing resistance. The standard package default is often a sound starting point.

Is NanoID shorter than UUID v4?

A 21-character, 64-symbol NanoID is visibly shorter than canonical 36-character UUID text while having a similarly large ideal random space. Its format and ecosystem guarantees differ.

Can I put NanoIDs directly in URLs?

Use a URL-safe alphabet such as letters, digits, _, and -, then test path routing and escaping. URL safety does not provide access control.

Why does the entropy card ignore duplicate alphabet characters?

It reports unique character count, but the generator still samples the original positions. Duplicates skew probabilities, so remove them rather than trusting that estimate.

Should production code copy IDs from this online NanoID generator?

No. Use it to explore configurations. Production should use the maintained Nano ID package or another CSPRNG-backed, unbiased implementation and enforce uniqueness at storage.