Nanoid Generator

This nanoid generator uses the browser's built-in Web Crypto API (crypto.getRandomValues) to produce cryptographically secure unique identifiers entirely in your browser. No data is transmitted to any server, making it completely safe for generating IDs you plan to use in real production systems.

When you click Generate Nanoids, the tool creates a Uint8Array of random bytes equal to the requested ID length. Each byte value is then reduced modulo the alphabet size to select a character from the chosen character set. Those characters are concatenated in sequence to form one complete nanoid. This process repeats for however many IDs you requested (up to 100 at once).

The generator offers eight built-in alphabets plus a fully custom option:

• Default — 64 characters: digits, uppercase, lowercase, underscore, and hyphen (0-9A-Za-z_-). This is the standard nanoid alphabet used by the official library.
• Alphanumeric — 62 characters: digits, uppercase, lowercase (0-9A-Za-z). Ideal when underscores and hyphens must be excluded.
• Lowercase — 26 characters (a-z). Useful for case-insensitive systems or human-readable codes.
• Uppercase — 26 characters (A-Z). Mirror of lowercase for systems that prefer capitals.
• Numbers — 10 characters (0-9). Produces a purely numeric token such as a PIN or OTP skeleton.
• Hexadecimal — 16 characters (0-9a-f). Matches the format expected by systems that work with hex digests.
• URL Safe — 66 characters: digits, uppercase, lowercase, hyphen, dot, underscore, tilde (0-9A-Za-z-._~). Every character survives a URL without percent-encoding.
• Custom — You supply any character set. The generator uses only those characters, giving full control over the output alphabet.

The ID length slider ranges from 8 to 64 characters, and the default of 21 is deliberately chosen to match the security level of UUID v4 while using fewer characters. You can generate up to 100 IDs per click and copy them individually or all at once.

One of the most important properties of any unique ID system is how likely it is that two independently generated IDs will be identical — a collision. The nanoid generator displays a real-time collision estimate based on the Birthday Paradox approximation, assuming IDs are generated at a rate of 1,000 per second.

The collision probability calculation proceeds in three steps. First, the total number of possible distinct IDs is computed as alphabetSize ^ length. For the default settings (64-character alphabet, length 21), this equals 64²¹ ≈ 9.2 × 10³⁷ possible combinations. Second, the birthday paradox approximation estimates the number of IDs you must generate before there is roughly a 1% chance of any two being identical: that threshold is approximately √(totalCombinations / 2). Third, dividing that threshold by the generation rate (1,000 per second × 31,536,000 seconds per year) converts it to years.

For the default nanoid configuration this yields a collision horizon of over a billion years, which the tool reports as "Practically impossible." Shorter IDs or smaller alphabets dramatically reduce this safety margin. For example, a 10-character numeric-only ID (10¹⁰ combinations) reaches its 1% collision threshold in under a second at 1,000 IDs/s.

This makes the collision probability display an invaluable sanity check when configuring a custom alphabet or shorter length for a specific use case.

UUID (Universally Unique Identifier) v4 has been the default choice for unique IDs in databases and APIs for decades. Nanoid was designed to solve several practical shortcomings of UUID while delivering equivalent or better security guarantees.

The key insight is that nanoid achieves slightly more entropy than UUID v4 in fewer characters by using a 64-character alphabet instead of hex. This makes nanoids better suited for URLs, database primary keys, and any context where string length matters for storage or display. UUID remains the right choice when you need RFC 4122 compliance or system interoperability with tools that specifically parse UUID format.

The alphabet you choose determines both the security strength and the compatibility of your generated IDs. Selecting an appropriate alphabet requires balancing three factors: the entropy needed, the systems that will store or transmit the ID, and any human-readability requirements.

Default (64 chars): Use this for general application IDs, session tokens, file names, and any context where the ID will not appear in a URL path segment. The underscore and hyphen characters are both URL-safe in most positions but can cause issues in certain regex or command-line contexts.

Alphanumeric (62 chars): The safest all-around choice when you need broad compatibility. Works in URLs, HTML attributes, JSON keys, SQL columns, and shell scripts without any escaping. Loses only a tiny amount of entropy compared to the default alphabet.

Lowercase (26 chars): Best when the receiving system is case-insensitive — for example, generating short readable codes for humans to type, or producing IDs that must work identically in case-insensitive databases or file systems (like NTFS on Windows).

Hex (16 chars): Appropriate when your system expects hex-format identifiers, such as cryptographic hash identifiers, color codes, or compatibility with tools that parse hex strings. At 21 characters the entropy is still substantial but noticeably lower than the default alphabet.

URL Safe (66 chars): All characters are defined as unreserved in RFC 3986, so these IDs can appear anywhere in a URL — path, query string, or fragment — without percent-encoding. Slightly larger than the default alphabet due to the addition of dot and tilde.

Custom: When you have very specific requirements — for example, generating activation codes that exclude ambiguous characters like 0, O, 1, and l — a custom alphabet gives you precise control. Enter exactly the characters you want; each unique character in your input becomes part of the alphabet.

Nanoids are a practical alternative to UUID in a wide range of software development and system design scenarios. Their compact size, URL-friendliness, and cryptographic security make them versatile identifiers that fit naturally into modern application architectures.

Database primary keys: Replacing auto-increment integers with nanoids decouples ID generation from the database, enabling distributed systems to generate valid IDs without coordination. Short nanoids also reduce storage overhead and improve index readability compared to UUID strings.

URL shorteners and slug generation: A short nanoid (8–12 characters, alphanumeric alphabet) provides billions of possible slugs while staying compact enough to share comfortably. The URL-safe character set ensures no percent-encoding complications.

Session tokens and CSRF tokens: Security-critical tokens need high entropy and unpredictability. A 32-character default nanoid provides over 192 bits of entropy — well above the 128-bit minimum recommended for session identifiers.

File and asset naming: Uploaded files often need unique names to avoid collisions and prevent enumeration attacks. Nanoids provide both properties while keeping filenames short enough to display cleanly in admin UIs.

Correlation IDs and trace IDs: In microservice architectures, a short nanoid added to each request as a correlation ID allows logs from multiple services to be joined without the overhead of a full UUID.

One-time codes and invite links: Using a shorter nanoid (10–16 characters) with the alphanumeric alphabet generates invitation tokens and password reset links that are long enough to be secure but short enough to include in a printed email without line-wrapping issues.