Nano ID Generator

What this tool is used for

• Producing a short URL-safe identifier for a record without a database sequence.
• Generating a public-facing id that does not reveal a row count.
• Creating an identifier short enough to appear in a path segment comfortably.
• Producing ids client-side so a record can be referenced before it is saved.
• Generating keys for a test fixture that must not collide.

Frequently Asked Questions

How does Nano ID compare with UUID?

21 characters versus 36, and a 64-character alphabet versus hex. A default Nano ID carries ~126 bits of entropy against UUIDv4's 122, so it is slightly stronger while being 40% shorter and URL-safe without escaping.

What alphabet does it use?

A-Za-z0-9 plus underscore and hyphen — 64 symbols, all safe in URLs, filenames and HTML attributes with no percent-encoding. That is the main practical advantage over Base64, whose + and / require escaping.

Is it cryptographically secure?

Yes. It uses crypto.getRandomValues rather than Math.random, and it applies rejection sampling so the alphabet is drawn uniformly with no modulo bias — a detail many hand-rolled ID generators get wrong.

How likely is a collision?

At the default 21 characters, generating a million IDs per second would take roughly a thousand years before a 1% collision probability. Shorter IDs degrade this sharply — at 8 characters you are into collision territory within millions of IDs.

Are Nano IDs sortable?

No — they are purely random with no timestamp, so they do not sort chronologically and they scatter B-tree inserts. If you need time-ordered IDs use ULID or UUIDv7 instead.

Can I shorten the ID safely?

Only against a known scale. Dropping to 10 characters leaves about 60 bits, which is fine for a URL slug within one small table and unusable as a global identifier — collision probability rises with the SQUARE of the number of IDs issued, not linearly.

Is a custom alphabet a good idea?

It is supported and it changes the maths. Removing ambiguous characters improves readability at the cost of entropy per character, so a shorter alphabet needs a longer ID for the same collision resistance — which is what the length calculation has to account for.

Does the ID length need to change with volume?

Yes — collision probability depends on how many you generate, not on how many exist at once. Twenty-one characters is sized for very large volumes; a shorter ID is fine for a small set and dangerous once that set grows.

Common errors and gotchas

• Shortening the id to save characters, which cuts entropy and raises the collision probability sharply.
• Treating an unguessable id as authorisation, when a URL leaks into logs, referrers and history.
• Expecting time ordering, which these ids do not provide.
• Assuming a shorter id is easier to dictate, when a case-sensitive alphabet makes it harder.
• Generating ids client-side without any server-side uniqueness check on a critical key.