How does Nano ID compare to UUID?

Both use cryptographically secure random sources. Nano ID is shorter (21 vs 36 chars), has more entropy per character, and has no hyphens — making it cleaner in URLs and databases.

Is the custom alphabet safe?

Yes, as long as it has at least 2 characters. For maximum security, use a large alphabet (64+ chars) to maintain high entropy per character.

Can I use Nano ID in a database as a primary key?

Yes. Nano IDs work well as VARCHAR primary keys in Postgres, MySQL, or SQLite. They're URL-safe by default, which makes them easy to expose in REST API paths. Unlike integers, they don't reveal the number of records in your database.

How do I prevent collisions?

With the default 21-char alphabet-64 alphabet, the probability of a collision in 1 billion IDs is about 1 in 10^15 — negligible for most applications. If you reduce the length for readability, verify acceptable collision probability for your scale using the Nano ID collision calculator.

Nano ID Generator

Generated locally — no server

Generate compact, URL-safe unique IDs using a cryptographically secure random source. Configurable alphabet and length.

Configuration

Size (characters)

Count (1–1000)

Alphabet

Custom Alphabet (optional, min 2 chars)

Runs entirely in your browser — nothing is uploaded

Runs in your browser

Next steps

UUID Generator

Recommended

Generate v4 UUIDs instantly — copy one or bulk-generate thousands.

Random Token Generator

Recommended

Generate cryptographically secure random tokens, API keys, and secrets.

Hash Generator

Generate secure MD5, SHA-256, and SHA-512 hashes from any text.

Slug Generator

Convert any text to clean URL slugs — lowercase, hyphenated, URL-safe.

View all tools →

Runs entirely in your browser. No uploads. Your files stay private.

What Is Nano ID?

Nano ID is a unique-string algorithm designed by Andrey Sitnik as a smaller, faster, URL-friendly alternative to UUID v4. The default output is 21 characters drawn from a 64-character URL-safe alphabet (A-Z, a-z, 0-9, underscore, dash), giving roughly 126 bits of entropy — slightly higher than UUID v4's 122 bits while shaving 15 characters off the length.

This generator implements the official algorithm directly rather than depending on the npm package, but the math is identical. It pulls cryptographically secure bytes from window.crypto.getRandomValues, the same Web Crypto primitive used by UUID v4 generators and by browsers' built-in crypto.randomUUID(). The values are not derived from Math.random, which is not safe for IDs that must be unguessable.

Each byte from getRandomValues covers 0-255, but the alphabet rarely has exactly 256 characters. To avoid modulo bias the generator computes a power-of-two mask (the smallest mask whose values cover the alphabet without skewing probability), reads bytes in chunks, and discards values that exceed the alphabet length. This is why the alphabet size affects both entropy and the speed of generation.

Custom alphabets are fully supported — you can pass an alphabet as small as two characters or as large as Unicode allows. The Entropy stat in the UI is calculated as length * log2(alphabetSize) and updates as you type. Smaller alphabets like hex or numeric reduce entropy per character; you can compensate by increasing length. The Nano ID collision calculator at zelark.github.io/nano-id-cc is a good companion for picking a size.

Common pitfalls: shrinking IDs below 8 characters with a small alphabet leads to real collision risk in any system that grows beyond a few thousand records; using a numeric-only alphabet creates IDs that can be confused for primary key integers in logs; and including ambiguous characters like O, 0, l, 1 in custom alphabets degrades human readability when IDs are shared verbally. The default URL-safe alphabet sidesteps the URL-encoding issues you would hit with characters like + or /.

Practical sizing: a 21-character Nano ID has a 1-in-10^15 collision probability for the first billion IDs, which is comfortably below the threshold most engineering teams consider acceptable. Dropping to 10 characters with the same alphabet is reasonable for systems generating millions of IDs but not billions; a 6-character ID is appropriate only for short-lived ephemera like share codes that expire in minutes.

Generation happens entirely in your browser. The bytes never leave the page, there is no rate limit, and you can request up to 1000 IDs at once for seeding test datasets or pre-allocating identifiers in offline-first applications.

Common Use Cases

Database primary keys

Use a 21-character Nano ID as a VARCHAR primary key when you want URL-safe identifiers without exposing record counts.

Session and CSRF tokens

Generate unguessable identifiers for sign-in flows, CSRF protection, or one-time confirmation links.

URL shortener slugs

Pair a smaller alphabet (lowercase + digits) with a 7-8 character length for short, type-safe links.

Upload file names

Avoid filename collisions in object storage by prepending or replacing user-supplied names with a Nano ID.

Frequently Asked Questions

Both draw from a cryptographically secure source. UUID v4 is 36 characters with hyphens and 122 bits of entropy. Nano ID's default is 21 characters, no hyphens, 126 bits, and uses an alphabet that does not need URL encoding. Nano ID also lets you tune size and alphabet; UUID v4 is fixed.

Yes. crypto.getRandomValues is required by the Web Crypto specification to be cryptographically secure. Browsers back it with the operating system CSPRNG (BCryptGenRandom on Windows, /dev/urandom on Linux, SecRandomCopyBytes on macOS).

Mapping a uniform byte 0-255 onto an alphabet whose length is not a power of two via modulo introduces bias — the lower indices appear more often. Nano ID's masking-and-rejection scheme guarantees a uniform distribution at the cost of occasionally rejecting a byte.

Yes, store it as VARCHAR or CHAR with the appropriate length. Compared to integer auto-increment keys it does not leak record counts and is safe to expose in URLs. Compared to UUIDs it indexes slightly better because of its shorter length.

Estimate the total IDs you will ever generate and consult the Nano ID collision calculator. As a rule of thumb, 21 chars is safe for 10^15 IDs, 12 chars for billions, 10 chars for hundreds of millions, 8 chars for millions, and 6 chars only for ephemeral short codes.

If it has at least two characters and you choose enough length to keep entropy high, yes. The masking scheme adapts to whatever alphabet you provide. For human-shared codes, exclude visually ambiguous characters like 0/O and 1/l/I.

No. Nano IDs are random and have no time component. If you need k-sortable IDs (insertion order roughly preserved by lexicographic sort), look at ULID or KSUID instead.

Yes — the official package is on npm, JSR, and most other ecosystems (Python, Rust, Go, Java, .NET, etc.) all have ports. The algorithm is small enough to inline if you cannot add a dependency.

The mask-and-reject loop discards bytes whose value exceeds the alphabet length. Alphabets just over a power-of-two boundary (e.g., 33 characters) reject more bytes than alphabets right at the boundary (32 or 64). The difference is microseconds per ID.

No. Generation runs entirely in your browser through crypto.getRandomValues. The IDs are kept in component state until you reload the tab and never sent over the network.