NanoID

What is NanoID?

NanoID is a tiny, URL-safe, unique ID generator. The default output is 21 characters drawn from a 64-character alphabet, giving roughly 126 bits of entropy - enough that the probability of any two IDs colliding is negligible. It was designed as a lighter, faster alternative to UUID for the places where a UUID's hyphens and length are inconvenient.

Unlike UUID, NanoID has no structure: it is pure randomness. There is no timestamp, no version field, no variant bits. That makes it ideal for URLs, filenames, session tokens, database IDs, and anything else where you want short opaque strings - and it makes it unsuitable for anything that needs to sort by creation time.

How to use

Set the quantity, length, and alphabet, then copy the output. Every change to a setting regenerates the batch.

The default alphabet is the URL-safe set used by the reference NanoID implementation - digits, uppercase letters, lowercase letters, _, and -. It excludes characters that require escaping in URLs or that look visually similar. If you need a different set, edit the alphabet field directly.

How much entropy do I need?

Roughly: length × log2(alphabet size) = bits of entropy. The default 21 chars × 6 bits = 126 bits. That is far beyond what is needed to avoid accidental collisions in any database you will ever build.

• 8 chars (48 bits) - enough for short-lived session tokens, cache keys, and rate-limit buckets.
• 12 chars (72 bits) - enough for user-facing short links where collisions must not happen.
• 21 chars (126 bits) - the reference default. Use it unless you have a specific reason not to.
• 32+ chars (192+ bits) - if you want a security margin beyond any realistic threat model.

NanoID vs UUID vs ULID

UUID v4 - 36 characters with hyphens, 122 bits of randomness, standardized in RFC 9562. Good for interoperability.

ULID - 26 characters, timestamp-prefixed, sortable. Good when chronological ordering matters.

NanoID - configurable length, alphabet, and no fixed format. Good when you want compactness and don't need ordering. Not a standard - it is a library convention, not an RFC.

FAQ

Is NanoID cryptographically secure?

Yes, if the underlying random source is. The reference implementation uses crypto.getRandomValues in the browser, which is a CSPRNG. This tool does the same. Do not confuse it with Math.random(), which is not secure and is used by some naive implementations.

Is NanoID standardized?

No. NanoID is a library, not an RFC. Its output format is only meaningful if both the producer and consumer agree on the same alphabet and length. For a standardized short opaque ID, use a UUID v4 or v7.

Why is the default length 21?

21 characters × 6 bits (from a 64-character alphabet) ≈ 126 bits, which matches the entropy of a UUID v4. It is a size chosen to make collisions as unlikely as UUID while keeping the string as short as possible.

Can I use NanoID as a database primary key?

Yes, but consider the trade-offs. NanoIDs do not sort, so your B-tree index will fragment under high insert load the same way it does with UUID v4. If sorting matters, use ULID or UUID v7 instead.

What is the modulo bias problem?

If you take random bytes and compute byte % alphabetSize, and alphabetSize does not evenly divide 256, some alphabet characters are slightly more likely than others. The reference NanoID implementation avoids this with a rejection-sampling step: it discards bytes above the largest multiple of the alphabet size. This tool does the same.