Skip to main content
Back to Numbers generators

Numbers

NanoID-Style Short ID Generator

Used by developers, writers, and creators worldwide.

A NanoID-style short ID generator produces compact, URL-safe unique identifiers that fit cleanly into URLs, API responses, and log files without the bulk of a standard UUID. At 21 characters, a NanoID matches UUID v4's collision resistance while being 36% shorter — a real difference when IDs appear thousands of times in network payloads or database rows. This generator lets you control three things: length (default 21), how many IDs to produce at once, and the character style — URL-safe alphanumeric, numeric-only, or hex. Adjust length down to 10–12 for human-readable invite codes, or push higher when uniqueness is mission-critical. Copy the batch straight into seed files, fixtures, or config.

Loading usage…

Free forever — no account required

How to use

  1. Choose your options above
  2. Click Generate
  3. Copy your result

Detailed instructions

  1. Set the ID Length field to match your use case — 21 for production systems, 10-14 for human-readable codes.
  2. Enter the number of IDs you need in the How Many field, up to hundreds for batch seeding or fixture files.
  3. Choose an ID Style: URL-safe for links and APIs, hex for systems expecting hexadecimal, numeric for digit-only pipelines.
  4. Click Generate to produce the batch, then review the list to confirm the format looks correct for your target system.
  5. Copy the output list directly into your seed file, config, or code, or download it as a text file for bulk use.

Use Cases

  • •Seeding a Postgres staging database with 200 non-sequential record IDs for integration tests
  • •Generating URL-safe slugs for Notion-style share links that avoid exposing auto-increment primary keys
  • •Creating numeric-only OTP-style tokens for SMS verification flows on platforms that reject non-digit input
  • •Populating idempotency keys in Postman collections to test duplicate-request handling in payment APIs
  • •Producing short correlation IDs to trace requests across microservices in a distributed system log

Tips

  • →Generate a batch of 50-100 at once and store them in a seed file — far faster than calling an ID library ad hoc during development.
  • →For invite or referral codes users will type, use alphanumeric style at length 10 and avoid ambiguous characters like O and 0 by choosing a restricted alphabet if available.
  • →Hex-style IDs pair naturally with systems that already use SHA hashes or Git commit SHAs, keeping your ID format visually consistent across the stack.
  • →When IDs appear in QR codes, shorter IDs reduce QR density and improve scan reliability — 12-14 characters is the sweet spot for printed media.
  • →Test your chosen ID in the target URL or database column before committing: paste a sample into your browser bar and your DB insert to catch encoding or length issues early.
  • →For distributed systems, combine a short location prefix (e.g., 'eu-' or 'us-') with a 16-character NanoID instead of using a longer single ID — aids debugging without sacrificing much brevity.

FAQ

how is a nanoid different from a uuid and which should I use

UUIDs follow a fixed 8-4-4-4-12 hyphenated format (36 chars) with 4 bits reserved for version info. NanoIDs are plain strings with no fixed structure, no baked-in hyphens, and a configurable length and alphabet — making them shorter and URL-safe by default without percent-encoding. If your system already expects UUIDs, stick with them; if you're starting fresh and IDs will appear in URLs or tight UI space, NanoID-style is the cleaner choice.

what id length is safe for my project without risking collisions

At 12 characters (URL-safe alphabet) you have ~68 billion possible values — enough for apps with under 100,000 records. At 21 characters the space is 3.7 × 10^37, making collisions effectively impossible at any realistic scale. For numeric-only style, increase length to at least 24–28 characters to compensate for the smaller alphabet.

are short random ids safe to use as database primary keys

They work well in document stores like MongoDB or DynamoDB, and as public-facing slug columns in relational databases. Random string PKs can cause B-tree index fragmentation on write-heavy relational tables, so a common pattern is keeping an internal auto-increment integer as the true primary key and storing the short ID as a unique indexed slug column.