Smart Deals - promotions, discount codes and sales

NanoID Generator

Short, random, URL-safe identifiers with the entropy reported in bits.

Secure (SSL)
Client-Side Processing
100% Free
Instructions
  • 1
    Enter data
    Enter content, paste text or load a file from disk.
  • 2
    Click the button
    The tool will immediately process your data in the browser.
  • 3
    Get the result
    Copy the finished text or save the file to your device.
function runTool() {
  return "Result ready in 0.1s";
}
Set the length and click Generate.

Rate this tool:

Related tools

Other tools you may find useful

NanoID generator - short random identifiers that are safe in a URL

The NanoID generator builds short identifiers drawn from the system cryptographic random source. You set the length, the number of identifiers and the character set, and the tool prints the results with the entropy expressed in bits. The default 21 characters from the URL-safe alphabet carry about 126 bits of randomness, more than UUID v4, in a form 15 characters shorter.

What NanoID is and where the 21 characters come from

NanoID is not a standard defined by an RFC document, it is a convention: take an alphabet, draw characters at random and join them into a string of a chosen length. The default 21 characters from the 64-character set A-Z a-z 0-9 _ - were picked so that the entropy beats UUID v4: 21 characters at 6 bits each is 126 bits, against 122 random bits in UUID v4, where six bits are spent on the version and variant fields.

Entropy, or how many bits you actually get

Every character contributes the base-2 logarithm of the alphabet size: exactly 6 bits for the URL-safe set, about 5.95 for the alphanumeric one, about 5.17 for lowercase letters with digits, and exactly 4 for hexadecimal. The tool prints the total above the list. A practical threshold: an identifier that acts as a secret in a public URL needs at least 120 bits, while one that only guarantees row uniqueness is fine with 60 to 80 bits.

NanoID, UUID v4, ULID and CUID2 side by side

FormatWritten lengthAlphabetSortable by timeRandomness
NanoID (21)21 characters64 characters: A-Z, a-z, 0-9, _, -no126 bits
UUID v436 characters with hyphens16 hex characters plus hyphensno122 bits
ULID26 characters32 characters, Crockford base32yes, 48-bit timestamp80 bits
CUID2 (24)24 charactersletters and digitsnoabout 120 bits

If you need a standards-compliant identifier, because a database column type or somebody else's API demands it, reach for the UUID generator. If the identifiers have to sort in creation order, the right choice is the ULID generator.

How to generate identifiers step by step

  1. Set the length between 4 and 128 characters. The default 21 matches classic NanoID.
  2. Enter how many identifiers you want, from 1 to 200. The tool makes sure the same identifier never appears twice in one list.
  3. Pick the alphabet. The number in parentheses is the set size, which together with the length decides the entropy.
  4. Click Generate, check the entropy above the list and copy everything with a single button.

Which alphabet to choose

The URL-safe set holds only characters that need no percent encoding in an address or a file name. The alphanumeric set drops the underscore and the hyphen, so it travels safely through systems that treat a hyphen as a separator. Lowercase letters with digits fit subdomain names and anywhere letter case is not distinguished. Hexadecimal is useful for integrations that accept nothing but digits and the letters a through f.

The set without look-alike characters drops zero together with the letter O, and the digit one together with I and L, the pairs people confuse when copying from a screen or a printout. That leaves 31 characters, about 4.95 bits each, so such a code has to be a little longer to reach the same entropy. Good for pickup codes and ticket numbers read out over the phone.

When a collision is a real risk

Collisions follow the birthday paradox: the probability of drawing two identical values grows with the square of their number, not linearly. With 126 bits of entropy and a billion identifiers generated, the chance of any collision at all stays below one in 10^20. The same arithmetic is brutal in reverse: four hexadecimal characters give only 65,536 possible values, so at two hundred draws a collision is more likely than not. That is why the generator rejects repeats inside a single list, and when the chosen length and alphabet cannot supply that many distinct values it says so instead of quietly returning fewer.

Why NanoID does not sort by time

The identifier carries no timestamp and no counter, every character is random. Sorting by such a key gives alphabetical order, unrelated to creation order. If the primary key should double as the natural ordering of your data, choose ULID or UUID v7. NanoID shines where the identifier has to be short and unguessable: in public links to shared resources, in invitation codes, in object storage file names.

A random identifier is neither a password nor a permission. If you use one to protect a resource, treat it as a secret: keep it out of logs in full, give it an expiry and check permissions server side. For human passwords the password generator is a better fit.

Frequently asked questions

Are 21 characters really enough?

Yes. With a 64-character alphabet, 21 characters give 126 bits of entropy, four bits more than UUID v4. Pushing the collision risk to one percent would take on the order of 10^18 identifiers.

Are the identifiers created in the browser?

No. The drawing happens on the server, through the PHP function random_int(), which pulls bytes from the operating system cryptographic generator. The result travels back to your browser and is not stored: the tool history keeps only the alphabet used and the number of identifiers, never the identifiers themselves.

Is NanoID suitable as a database primary key?

Yes, with two caveats. Store it in a fixed-length column such as CHAR(21) with binary comparison so the index stays compact. And remember that a random key scatters inserts across the whole index, which lowers write throughput on tables counted in hundreds of millions of rows. The usual answer is an increasing internal key plus NanoID as the public identifier in URLs.

Can I use a NanoID as a password?

We would not recommend it. The URL-safe alphabet has no special characters, so the identifier fails some complexity rules. For user accounts use a password generator that deliberately mixes uppercase and lowercase letters, digits and symbols.

How do I match the length to the use case?

Estimate how many values the system will ever produce and add headroom for the birthday paradox. For internal identifiers in the range of millions of rows, 12 URL-safe characters, that is 72 bits, is plenty. For public links stay at 21 characters; for single-use reset tokens take 32 with a short expiry.

Install Webp.pl Have the tools in your own pocket!