Skip to content
FindTool

    Nano ID Generator

    Generate compact URL-safe Nano IDs with a live collision-probability estimate.

    Nano ID Generator tool

    IDs before a 1% chance of one collision

    —

    —

    What this tool does

    It generates Nano IDs — compact, URL-safe identifiers built from a 64-character alphabet instead of hexadecimal. The default 21 characters carry 126 bits of randomness, four more than a UUID v4's 122, in 21 characters rather than 36. Size and alphabet are both adjustable, and the panel above recalculates the collision figure as you change them.

    Every ID comes from crypto.getRandomValues() with rejection sampling, so the character distribution is genuinely flat.

    Common uses

    • Public-facing record IDs in a URL, where /p/V1StGXR8_Z5jdHi6B beats a UUID.
    • Short share links and invite codes that a person might retype.
    • React keys, upload filenames and correlation IDs generated client-side.
    • Primary keys in a document store that does not care about index locality.
    • Replacing a sequence so IDs stop revealing how many rows you have.

    A short example

    Three IDs at the default size, with the UUID they would replace underneath:

    V1StGXR8_Z5jdHi6B-myT
    FyxG7q2LkPd0WnBc4tRhZ
    qO6mEwT1_aXsKdR9yB3uV
    
    1b9d6bcd-bbfd-4b2d-9b5d-ab8dfbbd4bed

    What the collision number means

    Nobody can promise random IDs never repeat, so the honest question is how many you can mint before a repeat becomes plausible. That is the birthday problem: with N possible IDs, the chance that n of them contain a duplicate is roughly 1 − e−n²/2N. Inverting it for a 1% risk gives n = √(2N · ln(1/0.99)).

    For the 21-character default that is about 1.3 × 1018 IDs — at a million a second you would pass it in roughly forty thousand years. Drop to 12 characters and the same 1% risk arrives after about 9.7 billion IDs; drop to 8 and it arrives after 2.4 million, which a busy table can reach inside a year. Each character you remove divides the safe count by eight, because the keyspace shrinks 64-fold and the bound takes its square root.

    Nano ID against the alternatives

    Against UUID v4, Nano ID is shorter for equal or better entropy and needs no hyphens, which is the whole pitch. Against UUID v7 it loses the time ordering, so for a primary key on a large table v7's index locality is worth more than fifteen saved characters. Against an auto-increment integer it gives up sortability and gains the property that nobody can enumerate your records by counting upwards.

    Worth knowing

    The default alphabet includes - and _, which are URL-safe but will be broken by a double-click selection in some terminals, and an ID can begin with a digit or a hyphen — so quote it in YAML and never use one as a bare CSS identifier. If IDs will be read aloud or copied off a screen, switch to the no-look-alikes alphabet, which removes the characters people confuse, and add a couple of characters to the size to make up the lost entropy.

    Frequently asked questions

    Is a Nano ID strong enough for a secret share link?

    Guessing is not the weak point; the journey the URL takes is. A link leaks through Referer headers sent to third-party scripts, through browser history and shared proxy logs, and through the preview fetch a chat client fires the instant someone pastes it. Treat the identifier as a bearer credential: give it a short expiry, bind it to one recipient where the flow allows, and invalidate it after first use.

    Is Nano ID specified anywhere, or is it just a library?

    There is no RFC behind it, only a widely ported JavaScript implementation, so nothing authoritative settles a disagreement between two ports. The default size of 21 and the 64-symbol alphabet A-Za-z0-9_- are conventions each port chooses to honour. Record both in your schema and validate against them: a service that quietly defaults to 12 characters shifts your safe-volume figure by eight orders of magnitude.