NanoID Generator

Yes. All randomness comes from crypto.getRandomValues (the Web Crypto API), which is a cryptographically secure pseudo-random number generator available in all modern browsers. The mask + rejection-sampling algorithm ensures each character in the output is uniformly distributed across the alphabet with no modulo bias. This makes NanoIDs suitable for security-sensitive identifiers like session tokens, API keys, and document IDs — as long as the alphabet and length provide sufficient entropy for your threat model.

The default 21 characters with the URL-safe alphabet (64 chars) gives 126 bits of entropy — essentially the same as UUID v4. For most applications this is more than enough. If you need shorter IDs (e.g. 10-char short URLs), use the collision estimator: it shows how many IDs you'd need to generate before a 1% collision probability at your chosen settings. As a rule of thumb, stay above 100 bits of entropy (at least 17 chars with the URL-safe alphabet) for any application generating millions of IDs.

Yes. Switch the preset to 'Custom' and type any characters you want. The minimum is 2 unique characters (though that would be very inefficient). Common custom alphabets include: numeric-only for human-readable short codes (e.g. 6-digit OTPs), uppercase-only to avoid visual ambiguity (no l/1 or O/0 confusion), or domain-specific sets like Crockford Base32. The duplicate characters are removed automatically — only unique characters count toward the alphabet size.

Both are cryptographically secure and practically collision-proof. Choose NanoID when: IDs appear in URLs (URL-safe by default, no percent-encoding needed), you want shorter IDs, or you need a custom alphabet. Choose UUID v4 when: your database column is typed UUID (PostgreSQL, MySQL UUID type), you need RFC-compliant identifiers, or your team/library already assumes hyphenated hex format. In JavaScript, NanoID is often preferred for application-layer IDs while UUID v4 is used for database primary keys.

When mapping random bytes to an alphabet whose size is not a power of 2, a naive modulo operation (byte % alphabetLength) introduces modulo bias — characters at the start of the alphabet appear slightly more often than others. The mask + rejection sampling approach fixes this: it masks each byte to the nearest power of 2 above the alphabet length, then discards any value ≥ alphabetLength and retries. This guarantees each character in the output has exactly equal probability, which matters for both security and statistical uniformity.

The collision estimator uses the birthday paradox formula: the number of IDs before a 1% collision chance is approximately √(2 × A^L × ln(1/(1−0.01))), where A is the alphabet size and L is the ID length. For the default 21-char URL-safe NanoID (64-char alphabet), you'd need ~2.7 × 10^17 IDs before hitting 1% collision risk — at 1 million IDs per second, that's over 8 billion years. In practice, NanoID collisions are not a concern for any realistic workload.