Nano ID Explained: A Shorter, Safer Alternative to UUID

A Nano ID is a random string built from a fixed alphabet, generated to be practically unique across every ID you will ever create. The default alphabet uses 64 URL-safe characters - uppercase and lowercase letters, digits, underscore, and hyphen - and the default length is 21 characters. At that size, the ID carries roughly as much entropy as a UUID v4, just packed into 15 fewer characters and without any hyphens breaking up the string.

Unlike a UUID, which follows a rigid format defined by an RFC, a Nano ID is just a string of characters drawn from whatever alphabet you choose. That flexibility is the whole point: you decide the size and the character set, and the amount of randomness scales with both.

Size: 21 · Alphabet: A-Za-z0-9_-

V1StGXR8_Z5jdHi6B-myT

UUIDs are a well-known standard, but the format was designed for interoperability across systems, not for compactness. A Nano ID trades that standardization for practical wins in everyday code:

• Shorter strings - 21 characters instead of 36, which matters in URLs, filenames, and anywhere character count is visible or billed.
• No escaping needed - every character in the default alphabet is already URL-safe, so it drops straight into a path segment or query parameter.
• Tunable size - you can shrink the ID for a friendlier short link, or grow it for extra headroom, and see the collision impact immediately.
• Custom alphabets - restrict the character set to digits, lowercase letters, or a set without look-alike characters for anything a human has to type.

None of this makes Nano ID a strict replacement for UUID everywhere. If you are interfacing with a database column typed as UUID, or a system that expects the RFC 4122 format, stick with a UUID Generator. Nano ID shines when you control both ends and just need a compact, unique string.

Generating an ID means picking size characters at random from an alphabet, one at a time. The naive approach - alphabet[Math.floor(Math.random() * alphabet.length)] - has two problems: Math.random is not cryptographically secure, and a plain modulo over a non-power-of-two alphabet length introduces a small statistical bias toward earlier characters.

A correct implementation instead pulls random bytes from crypto.getRandomValues and uses rejection sampling: it discards any byte that would produce a biased result and draws again. That keeps every character in the alphabet equally likely, which is exactly what the collision-probability math assumes.

The number of possible IDs grows exponentially with size, so small changes matter a lot. Dropping from 21 to 12 characters in the default alphabet does not shrink your ID space by half - it shrinks it by many orders of magnitude, because each removed character divides the total space by 64. That is why sizing should be a deliberate decision, not a guess.

1. Open the Nano ID Generator and start from the default size of 21 characters.
2. Set the alphabet - keep the URL-safe default, or switch to something narrower like digits only, lowercase only, or a set with ambiguous characters (0, O, I, l) removed for IDs a human might read aloud.
3. Watch the live collision estimate as you adjust the size. It tells you roughly how many IDs you can generate before a collision becomes likely at your chosen length and alphabet.
4. Enter the quantity you need and generate in bulk, then copy a single ID or the whole list.

• Short IDs for public URLs, share links, and slugs.
• Database identifiers where a compact key is preferable to a full UUID.
• Coupon, invite, and referral codes built from a readable custom alphabet.
• Filenames and object keys that must be URL-safe without escaping.
• Client-generated keys for optimistic UI updates, before the server assigns a canonical ID.

Shrinking the size without checking the collision math

It is tempting to cut a Nano ID down to six or eight characters because it looks cleaner in a URL. That is fine for low-volume codes, but at high volume it can mean a meaningful chance of collision within months rather than centuries. Always check the estimate for your actual expected volume before shrinking.

Narrowing the alphabet without lengthening the ID

Switching to a digits-only or lowercase-only alphabet reduces the number of choices per character, which lowers total entropy even if the size stays the same. If you need a narrower alphabet for human readability, compensate by generating a longer ID.

Treating a Nano ID as a password or signing secret

A Nano ID is designed for uniqueness, not for secrecy under adversarial guessing at scale. For session tokens, API keys, or anything a password-strength adversary might brute-force, use a Password Generator or a purpose-built token designed for that threat model.

Assuming IDs sort or reveal creation order

Nano IDs are fully random by default - unlike some UUID variants or auto-incrementing keys, they carry no timestamp or sequence information. Do not rely on sorting Nano IDs to reconstruct creation order; store a separate timestamp if you need that.

• Stick with the default 21-character size unless you have a specific reason and have checked the collision estimate for your volume.
• Keep the default URL-safe alphabet for anything that ends up in a URL, so you never need to encode it.
• Use a custom, no-look-alike alphabet only for IDs a human will read or type, like referral or invite codes.
• Generate IDs in bulk when seeding test data or fixtures, rather than calling the generator one at a time.
• Reserve a UUID Generator for systems that specifically require the RFC 4122 format, and use Nano ID everywhere else you control both sides.