Nano IDs

Nano ID is a reaction to two things about UUIDs: how long they are, and how badly they fit in a URL. The canonical form is 36 characters, four of them hyphens, and the remaining 32 are drawn from an alphabet of only sixteen — hexadecimal is a wasteful way to carry randomness. The alternative had been standing in plain sight since October 2006, when Simon Josefsson's RFC 4648 specified a URL- and filename-safe variant of base64 that swaps + and / for - and _, so an encoded value survives a path segment, a query string and a filesystem untouched.

Andrey Sitnik, better known for PostCSS and Autoprefixer, published Nano ID in 2017 on exactly that basis. The defaults encode a set of deliberate judgements. Twenty-one characters from a 64-character alphabet give 126 bits, slightly more than the 122 random bits in a version 4 UUID, in fifteen fewer characters. Randomness comes from the platform's cryptographic generator — crypto.getRandomValues in a browser, crypto.randomBytes in Node — rather than Math.random, with a separate nanoid/non-secure entry point for callers who would rather have the speed and know what they are giving up. For custom alphabets the implementation masks bits and discards out-of-range samples instead of taking a modulo, which would quietly over-represent the first characters of any alphabet whose size is not a power of two.

It displaced its predecessor fairly completely: the older shortid package is now deprecated on npm with a note pointing at Nano ID. Ports followed for Go, Rust, Python, Java, PHP, Ruby, Swift and many other languages, and version 4 of the JavaScript package dropped CommonJS support, which left a long tail of projects on version 3.

The trade-off is explicit. A Nano ID holds no timestamp, counter or machine identifier, so it leaks nothing about where or when it was made — and sorts in no useful order at all, the opposite of the choice UUID version 7 and MongoDB's ObjectId make.

Key properties

• The default alphabet is 64 characters — A–Z, a–z, 0–9, hyphen and underscore — which is the base64url set defined in RFC 4648 section 5.
• The default length is 21 characters, which at 6 bits per character is exactly 126 bits of entropy.
• A 21-character Nano ID carries 126 bits against a version 4 UUID’s 122, in 21 characters rather than 36.
• Every character of the default alphabet is safe unescaped in a URL path, a query string, a filename and an HTML attribute.
• At 1,000 IDs per hour, reaching a 1% chance of a single collision takes roughly 149 billion years at the default length — the figure quoted by the library’s own collision calculator.
• Because 64 divides 256, the default alphabet needs no bias correction; the rejection-sampling path in the reference implementation exists for alphabets whose size is not a power of two.
• A Nano ID contains no timestamp, counter or machine identifier, so the IDs neither sort by creation time nor disclose anything about their origin.
• The IDs on this page are generated from a seeded, non-cryptographic PRNG, which makes them reproducible from the URL and therefore unsuitable as real identifiers.

Where they turn up

• Short IDs of this shape are the usual choice for public-facing URL slugs — a shared document or paste link — where a 36-character UUID would dominate the address.
• Prefixed random identifiers such as cus_ or evt_ are a common API convention: the tag names the object type for a human reading a log, while the random tail does the actual work.
• Client-generated keys in offline-first and local-first applications need to be unique before any server sees them, which rules out database sequences and makes a short random ID the natural fit.
• React and other UI libraries use short random strings as list keys and element ids, where only uniqueness within the page matters.
• Nano ID itself is a dependency of a large number of JavaScript build tools and frameworks, which is how most projects end up with it transitively rather than by choosing it.