About

NanoID is a compact, URL-safe, cryptographically strong identifier format. A standard UUID v4 occupies 36 characters to encode 122 bits of entropy. A default NanoID packs comparable collision resistance into 21 characters by using a 64-symbol alphabet (A - Z, a - z, 0 - 9, _, -), yielding 126 bits of entropy. Misconfiguring the alphabet size or ID length is the primary source of collision risk in distributed systems. Dropping to a 10-character hex ID, for example, reduces entropy to roughly 40 bits - a collision becomes probable after only ~1.05 million records. This generator uses the browser crypto.getRandomValues() CSPRNG and applies mask-based rejection sampling to eliminate modulo bias across arbitrary alphabet sizes.

The collision probability panel below computes the exact Birthday Paradox estimate for your configuration. Note: the tool assumes uniform random distribution. If you supply an alphabet with duplicate characters, effective entropy decreases and the estimate becomes optimistic. For database primary keys, maintain at least 100 bits of entropy. For short-lived session tokens, 64 bits may suffice.

Formulas

The core entropy per character is derived from the alphabet size A:

H_char = log₂(A)

Total entropy for an ID of length L:

H_total = L × log₂(A)

Collision probability after generating n IDs is approximated by the Birthday Paradox:

p ≈ 1 − e^{−n²2 ⋅ A^L}

The mask for rejection sampling is the smallest bitmask m satisfying:

m = (2^{⌈log₂(A)⌉}) − 1

A random byte is bitwise ANDed with m. If the result ≥ A, the byte is discarded and a new one is drawn. This eliminates modulo bias entirely.

Where: A = alphabet size (number of unique characters), L = ID length, n = number of IDs generated, H = entropy in bits, p = collision probability, m = bitmask for rejection sampling.

Reference Data

Alphabet Name	Characters	Size	Bits per Char	Default Length	Total Entropy (bits)	Use Case
Default NanoID	A-Za-z0-9_-	64	6.00	21	126	General purpose, URL-safe
Hexadecimal	0-9a-f	16	4.00	32	128	Hash-like tokens
Decimal	0-9	10	3.32	21	69.7	Numeric codes, PINs
Lowercase Alpha	a-z	26	4.70	21	98.7	Human-readable slugs
Uppercase Alpha	A-Z	26	4.70	21	98.7	License keys, serial numbers
Alphanumeric	A-Za-z0-9	62	5.95	22	131	Database keys
Base32 (Crockford)	0-9A-HJKMNP-TV-Z	32	5.00	26	130	Unambiguous human input
No Look-Alike	2-9A-HJ-NP-Za-km-z	57	5.83	22	128	Printed codes (no 0/O/l/1)
URL-Safe Base64	A-Za-z0-9-_	64	6.00	21	126	JWT-compatible tokens
Binary	01	2	1.00	128	128	Bit strings, testing
Octal	0-7	8	3.00	43	129	File permissions, legacy
UUID-Compatible	0-9a-f + hyphens	16	4.00	32	128	Drop-in UUID replacement
Emoji Set	Selected emoji	256	8.00	16	128	Fun identifiers, demos

Frequently Asked Questions

NanoID uses mask-based rejection sampling. It computes a bitmask equal to (2^⌈log₂(A)⌉ - 1), where A is the alphabet size. Each random byte is ANDed with this mask. If the resulting value is ≥ A, the byte is discarded and another is drawn. This guarantees every character in the alphabet has an exactly equal probability of selection, unlike a simple modulo operation which would skew distribution toward lower-indexed characters.

For database primary keys in systems generating fewer than 1 billion records, 100 bits of entropy is generally safe. The default NanoID configuration (21 characters, 64-symbol alphabet) provides 126 bits, which means you would need to generate roughly 2.2 × 10¹⁸ IDs before reaching a 1% collision probability at 1,000 IDs/second. If your alphabet or length is smaller, use the collision probability panel in this tool to verify your configuration meets your throughput requirements.

UUID v4 provides 122 bits of entropy in 36 characters (including 4 hyphens). NanoID default provides 126 bits in 21 characters - 42% shorter with slightly more entropy. NanoID is URL-safe by default with no special characters beyond hyphen and underscore. It also allows custom alphabets, so you can tailor IDs to your system constraints (e.g., case-insensitive databases, numeric-only systems).

Yes. Duplicate characters reduce the effective alphabet size. If you specify "aabcdef" (7 characters but only 6 unique), the effective A = 6, not 7. The entropy calculation and collision probability become optimistic because the tool counts unique characters. Additionally, the character "a" will appear roughly twice as often as others, creating a non-uniform distribution detectable by statistical analysis. Always use unique characters in your alphabet.

crypto.getRandomValues() is a cryptographically secure pseudorandom number generator (CSPRNG) specified in the W3C Web Cryptography API. It draws from the operating system's entropy pool (e.g., /dev/urandom on Linux, BCryptGenRandom on Windows). It is suitable for generating session tokens, API keys, and nonces. However, the security of the final token also depends on sufficient entropy (length × log₂(alphabet size) ≥ 128 bits recommended) and secure transmission (HTTPS).

For the default 64-character alphabet (a power of 2), rejection never occurs - every byte is valid. For non-power-of-2 alphabets, the worst case is alphabet size 33 (mask = 63), where approximately 47.6% of bytes are rejected. The generator compensates by requesting extra bytes upfront (step size = ceil(1.6 × L)). For a batch of 1,000 IDs at length 21 with a 33-char alphabet, expect roughly 35,000 random bytes consumed - negligible for crypto.getRandomValues() which can produce millions of bytes per second.