NanoID Generator
Create short, URL-safe NanoIDs with custom length, alphabet and prefix, plus a collision-risk estimate.
Tool guide
What this tool does
NanoID Generator produces compact random IDs using the nanoid library and your browser’s cryptographic random source. Choose the length and alphabet, add a prefix such as usr_, generate thousands at once and see how many IDs you could create before the chance of a collision reaches 1%.
Not every identifier needs to be a 36-character UUID. Short links, invite codes, file names and public object IDs read better when they are compact, but making an ID shorter or restricting its characters reduces the number of possible values. Choose too little entropy and two records will eventually get the same ID.
This generator uses nanoid’s customAlphabet function, which draws bytes from the Web Crypto API and uses masking to avoid the modulo bias that a naive random-character picker introduces. The default of 21 characters from a 64-symbol URL-safe alphabet gives 126 bits of entropy, close to a UUID v4’s 122 bits. The collision panel applies the birthday bound, n ≈ √(2N · ln(1/(1 − p))), to estimate how many IDs and how much time it takes to reach a 1% chance of any duplicate at your generation rate.
How to use NanoID Generator
- Set the ID length with the slider (2 to 64 characters).
- Choose an Alphabet preset, or Custom alphabet to type your own characters.
- Optionally add a Prefix, for example ord_ or inv-, to make IDs self-describing.
- Enter How many and choose an Output format, then click Generate.
- Under Collision risk, enter how many IDs your system creates per hour and read the entropy and time estimates.
- Shorten or lengthen the ID until the time to reach 1% risk comfortably exceeds your system’s lifetime.
Tips for better results
- The No look-alikes alphabet removes characters such as 1, l, I, 0 and O, which is ideal for codes people type from paper or read aloud.
- Each extra character from a 64-symbol alphabet adds 6 bits of entropy; a hex character adds only 4.
- A prefix does not add entropy, so keep the random part long enough on its own.
- If IDs must be case-insensitive, for example in email addresses or some file systems, use the lowercase + digits alphabet.
Common use cases
- Short public IDs for URLs, such as /p/V1StGXR8_Z5jdHi6B-myT.
- Coupon, invite and referral codes with a readable alphabet.
- Client-side temporary keys for list items and offline drafts.
- Prefixed resource IDs like usr_, org_ or key_ in an API design.
Common mistakes to avoid
- Cutting the length to 6 or 8 characters for a high-volume table without checking the collision estimate.
- Using a numbers-only alphabet for long-lived public IDs; 10 symbols give far less entropy per character.
- Assuming uniqueness is enforced. Always keep a unique index in the database and retry on the rare conflict.
Frequently asked questions
Is NanoID secure enough for tokens?
The randomness comes from crypto.getRandomValues, so the IDs are unpredictable. For secrets such as password-reset links, use at least 21 characters from a 64-symbol alphabet and still apply expiry and rate limits.
How does NanoID compare with UUID v4?
The default NanoID packs 126 random bits into 21 characters, while a UUID v4 has 122 random bits spread over 36 characters. NanoID is shorter and URL-safe; UUIDs are a standard format many databases store natively.
Why does a custom alphabet remove duplicate characters?
A repeated character would appear more often than the others and skew the distribution, lowering the real entropy. Removing duplicates keeps every symbol equally likely.
How accurate is the collision estimate?
It uses the standard birthday-problem approximation, which is very close for the large ID spaces involved here. Treat it as an order-of-magnitude guide for choosing a length.
Feedback & suggestions
Help us improve NanoID Generator. We read every message.