NanoID Generator

Generate NanoID values online: 21 URL-safe characters by default, about 126 bits of randomness, with custom length and alphabet.

Format
Generated IDs
Ready. Generate NanoID values in your browser.

How this ID is built

Layout
21 URL-safe characters by default from A-Z, a-z, 0-9, underscore and hyphen.
Entropy
About 126 bits with the default 64-character alphabet and 21-character length.
Time
No timestamp; NanoID values are opaque unless you put meaning into a custom alphabet.
Collision risk
Collision risk changes with length and alphabet. The default is in the same practical safety range as UUID v4.
Example
uLhtcwG3tMk5j1nIK9ZiE

Your IDs are generated locally with strong browser randomness. Nothing is sent to BroBroGo.

FAQ

Why use NanoID?

NanoID is shorter than a UUID, URL-safe by default and still has high randomness when you keep the default length and alphabet.

Can I change the alphabet?

Yes. The locked NanoID page keeps the length and alphabet controls. Smaller alphabets or shorter lengths raise collision risk.

How Nano ID Works and Why It Exists

Nano ID is a compact, URL‑safe identifier format that produces shorter strings than UUID v4 (36 characters) or ULID (26 characters) without sacrificing collision resistance. By default, a Nano ID is 21 characters long and uses a 64‑symbol alphabet (A-Za-z0-9_-). That set excludes characters that can cause problems in URLs (e.g., +, /, =) and avoids ambiguous pairs like l and 1 or O and 0. The generator on this page implements the same algorithm: for each character it picks a random symbol from the alphabet using crypto.getRandomValues, the browser’s cryptographically strong random number generator.

The format supports arbitrary length and alphabet. The page exposes two controls: a Length slider (range 2–36, default 21) and an editable Alphabet text field (default the 64 URL‑safe characters). Changing either parameter immediately regenerates all displayed IDs with no button press needed.

Configuring Length and Alphabet

Length can be set between 2 and 36 characters inclusive. The lower bound ensures even a short token still has some combinatorial space; the upper bound is a practical cap for the format. The slider snaps to integer values, and the generated IDs update on every tick.

Alphabet is an editable string. The initial value is:

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_

You may delete, rearrange, or replace characters. Typical modifications include:

  • Numeric only – set alphabet to 0123456789 to produce numeric strings like 8392047.
  • Hex only – set alphabet to 0123456789abcdef for hex tokens (a3f2b1).
  • Remove ambiguous characters – delete 0O, 1l, or -_ to avoid confusion when IDs are read by humans.
  • Increase set size – add symbols like !@#$% if the use case permits, though URL safety is lost.

Changing the alphabet immediately regenerates the IDs, provided the new string contains at least two distinct characters. If the rule is violated, the tool clears the results.

Alphabet Constraints and Error Handling

The alphabet must contain at least two different characters. A single‑character alphabet (e.g., A) makes every generated ID identical: a string of repeated As. That destroys any collision resistance – every ID of length n would be the same value. The tool enforces the minimum by:

  • Clearing the result list.
  • Setting the ID count to 0.
  • Disabling the Copy all button.
  • Showing the error message: Alphabet needs at least 2 different characters.

Whitespace is treated as a valid character if present, but it can break URL safety. The tool does not strip whitespace – it becomes part of the alphabet. Leading or trailing spaces in the alphabet field are included. For reliable URL‑safe generation, keep the alphabet clean and without spaces.

If the alphabet contains duplicate characters (e.g., AABC), the duplicates are not deduplicated. They remain in the set, increasing the probability of those characters relative to others. That is intentional – the user may want weighted distributions. The tool does not modify the alphabet string.

Collision Resistance and Probability

The probability of two Nano IDs colliding depends on three factors: length (L), alphabet size (A), and the number of IDs generated (N). The total number of possible IDs is A^L. For the default (21 characters, 64 symbols) that is 64²¹ ≈ 1.1 × 10³⁸ possibilities – astronomically larger than the total number of UUID v4 values (2¹²² ≈ 5.3 × 10³⁶).

The birthday problem dictates collision risk: for a 1% chance of at least one collision, you can generate roughly √(2 × 0.01 × A^L) IDs. For the defaults:

  • A = 64, L = 21 → √(2 × 0.01 × 64²¹) ≈ √(2.2 × 10³⁶) ≈ 1.5 × 10¹⁸ IDs.
  • That means you would need to generate over a quintillion (10¹⁸) IDs before hitting a 1% collision probability.

If you shorten the length or reduce the alphabet size, the safe generation count drops. Examples:

Length Alphabet size IDs for 1% collision probability
21 64 ~ 1.5 × 10¹⁸
10 64 ~ 1.8 × 10⁸
8 36 (alphanumeric, no case) ~ 5.4 × 10⁵
6 10 (digits) ~ 1.1 × 10³

For low‑risk applications (e.g., short‑lived tokens, non‑critical database keys), a shorter length is acceptable. For security‑sensitive tokens (session IDs, API keys), use at least 21 characters with the full URL‑safe alphabet.

Client‑Side Generation and Privacy

All ID generation happens in the browser using crypto.getRandomValues. No data – not the alphabet, not the length, not the generated IDs – is sent to any server, including BroBroGo. The page works fully offline after the first load. This is a deliberate privacy design: the tool can be used for sensitive identifiers without exposing generation patterns or content to a network.

crypto.getRandomValues is available in all modern browsers (Chrome, Firefox, Safari, Edge) and provides cryptographically strong random bytes. The algorithm maps those bytes onto the chosen alphabet in a uniform way, rejecting out‑of‑range values to avoid bias. The generation is deterministic only in the sense that the same browser, same user, and same environment will produce different IDs each call – no seed is exposed.

Use Cases and Comparison to UUID / ULID

Nano ID is often chosen over UUID or ULID when:

  • Storage size matters – A 21‑character Nano ID (21 bytes) takes less space in a database index than a UUID (36 characters, typically stored as 16 bytes binary or 36 bytes text). Nano ID’s length is adjustable, so you can go as low as 2 characters for very small lookup tables.
  • URL safety is required – The default alphabet contains no characters that need percent‑encoding. UUIDs include dashes, and ULIDs use uppercase letters but still contain dashes.
  • Human readability is secondary – Nano IDs are shorter but less memorable than UUIDs. They are meant for machines and copy‑paste workflows.
  • Custom constraints exist – Some systems require IDs that fit into limited character sets (e.g., only digits for SMS short codes, only lowercase for case‑insensitive environments). The page lets you specify exactly that alphabet.

UUID v4 remains standard for systems that must interoperate with existing UUID‑based infrastructures. ULID adds a time‑sorted component, useful for database indexing by creation order. Nano ID has no time element; ordering is random. For many applications – like generating unique filenames, tracking IDs for analytics, or creating short‑link slugs – Nano ID’s combination of compactness and adjustability wins.

FAQ

1. What is the minimum length I can set?
Length can be as low as 2 characters. An ID of length 2 with the default 64‑symbol alphabet gives 4096 possible values – fine for very small datasets but risky for anything larger.

2. Can I generate more than 100 IDs at once?
No. The count slider is limited to 1–100. If you need more, you can click the Copy all button and paste into a text editor, then repeat generation. Each generation produces new random IDs.

3. Does the tool check if generated IDs are unique among themselves?
Yes, the tool ensures no duplicate IDs appear in a single batch. If by chance the random process produces two identical values (rare with default settings), only one is shown and the count is adjusted.

4. What happens if I include a space in the alphabet?
Spaces become valid characters. An ID like abc def would contain a space, which may break URL handling and most text processing. Spaces are not recommended. The tool does not warn about them.

5. How is the default alphabet URL‑safe?
It contains only unreserved characters from RFC 3986: letters, digits, hyphen (-), and underscore (_). No percent‑encoding is needed when these IDs appear in paths, query parameters, or fragments.

6. Why does the alphabet need at least two different characters?
A single‑character alphabet always produces the same ID (e.g., AAAA...). That defeats the purpose of a unique identifier. The tool blocks this case to avoid confusing output.