Skip to main content
Back to Numbers generators

Numbers

CUID-Style ID Generator

Used by developers, writers, and creators worldwide.

A CUID-style ID generator creates collision-resistant unique identifiers designed for databases, distributed systems, and APIs. Unlike UUIDv4, CUID-format IDs embed a timestamp at the front, so records sort in rough creation order without extra indexing work. That makes them a practical default for primary keys in any system where multiple nodes write simultaneously. Each ID uses only lowercase alphanumeric characters, so it drops cleanly into URLs, JSON payloads, and file names without encoding issues. The prefix field lets you namespace by entity type — 'u' for users, 'o' for orders, 'p' for products — giving you an instant visual cue when reading logs or inspecting a database. Generate up to a custom count in one click and paste the list straight into a fixture file or seed script.

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 count field to how many CUID-style IDs you need, for example 10 for a database seed batch.
  2. Enter a prefix letter that matches your entity type, such as 'u' for users or 'p' for products.
  3. Click Generate to produce the full list of unique IDs instantly.
  4. Copy the output list and paste it directly into your fixture file, seed script, or API docs.

Use Cases

  • •Seeding a Postgres or MySQL staging database with timestamped primary keys for 50–200 test rows
  • •Generating prefixed IDs like 'u...' for users and 'o...' for orders in a Prisma or Drizzle schema prototype
  • •Populating Postman collection examples or OpenAPI spec docs with real-format CUID identifiers
  • •Creating URL-safe resource identifiers for REST routes like /orders/o8xk2m... without percent-encoding
  • •Building Jest or Vitest fixture files that need realistic, non-colliding IDs across distributed test runs

Tips

  • →Use a different prefix per entity type in the same project — it makes raw database dumps dramatically easier to read.
  • →When seeding a relational database, generate IDs for parent records first so you can reference them in child fixture rows.
  • →If you need IDs for API documentation, generate 3–5, then hardcode them as constants so examples stay consistent across doc pages.
  • →CUIDs sort well in most B-tree indexes because the timestamp prefix reduces page splits — prefer them over UUIDv4 for write-heavy tables.
  • →Paste a batch into a spreadsheet column to quickly build a mock dataset with realistic-looking IDs alongside other generated data.
  • →If your framework enforces a specific ID length, verify the output length first — CUID and CUID2 differ in length, so check compatibility before committing to a schema.

FAQ

how is a cuid different from a uuid for database primary keys

UUIDv4 is fully random, so rows have no natural sort order in a B-tree index. CUID-format IDs embed a timestamp at the front, meaning inserts land in roughly chronological order without a separate created_at sort. They also skip the hyphens that UUIDs include, which avoids escaping issues in URLs and some ORMs.

are cuid-style ids safe to expose in public urls or api responses

Generally yes — they contain only lowercase letters and digits, so no percent-encoding is needed in URL path segments or query strings. Worth noting: the timestamp component encodes approximate creation time, so if hiding that is a requirement, a fully random format like UUIDv4 is a better fit.

can i use these generated cuids directly in a node.js or javascript project

As static values, yes — paste them into seed scripts, fixture files, or API docs and they'll work fine. For runtime generation in production code, install the 'cuid2' npm package instead. This generator is best suited for pre-made batches where you need real-looking IDs without running any code.