Nano ID Generator
Generate compact, URL-safe unique IDs using a cryptographically secure random source. Configurable alphabet and length.
Generated locally — no server
Generate Nano IDs — compact, URL-safe unique identifiers shorter than UUIDs (21 chars by default vs 36) but still collision-resistant for most application scales. Configure alphabet (URL-safe by default, or custom for IDs that look like "3FaCe2Pop"), size, and count. Useful for short URLs, public-facing IDs in your app, and any place a UUID feels visually too noisy. Generation uses Crypto.getRandomValues for genuine entropy. IDs are produced locally, never logged.
Configuration
Runs in your browser
Next steps
UUID Generator
RecommendedGenerate v4 (crypto-random) or v1 (time-based) UUIDs instantly — copy one or generate a batch.
Random Token Generator
RecommendedGenerate cryptographically secure random tokens, API keys, and secrets.
Hash Generator
Generate MD5, SHA-1, SHA-256, and SHA-512 hashes from any text — MD5/SHA-1 for checksums, SHA-256/512 for integrity.
Slug Generator
Convert any text to clean URL slugs — lowercase, hyphenated, URL-safe.
Runs right inside your browser tab. 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 with the default 64-character alphabet gives 126 bits of entropy, meaning the collision probability remains astronomically small — far below any threshold that engineering teams consider a concern — even at billions of generated IDs. 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.
What in-browser generation buys you here: there is no rate limit because there is no API in the loop. Requesting 1,000 IDs at once for a test suite costs the millisecond your CPU takes to call crypto.getRandomValues, not a round trip to a remote endpoint. That also means the tool keeps working on planes, in tunnels, inside corporate networks that block external services, and in air-gapped environments where the browser is the only thing online. The generated IDs are kept in component state and are gone the moment you close the tab — paste them into your fixture file, your seed script, or your share-code mint, and the source of truth lives wherever you put them, not on a server we run.
Common Use Cases
01
Database primary keys
Use a 21-character Nano ID as a VARCHAR primary key when you want URL-safe identifiers without exposing record counts.
02
Session and CSRF tokens
Generate unguessable identifiers for sign-in flows, CSRF protection, or one-time confirmation links.
03
URL shortener slugs
Pair a smaller alphabet (lowercase + digits) with a 7-8 character length for short, type-safe links.
04
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 without any file leaving your device through crypto.getRandomValues. The IDs are kept in component state until you reload the tab and never sent over the network.
Advertisement