What this tool does

The UUID / ULID Generator produces unique identifiers in three popular formats, in any quantity from 1 to 1,000 at a time, with one-click copy and download. Every byte of randomness comes from crypto.getRandomValues, the browser's cryptographic RNG, never from Math.random.

The tool is meant for the moments when you need an ID right now: seeding a database, building a fixture file, generating a one-off API key for testing, populating an idempotency-key column, fabricating session IDs for a load test, or just confirming what a v4 UUID actually looks like before you commit to it as a column type.

The three formats, briefly

UUID v4 (RFC 4122)

The familiar 36-character hyphenated identifier: xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx. 122 bits of randomness with two fixed bits identifying the version (4 = random) and the variant. The collision probability on a single machine generating one billion UUIDs per second for a hundred years is still negligible, close enough to "never" for any practical workload.

UUID v4 is the right default when you need a globally unique identifier and you don't care about ordering. It's supported natively in Postgres (uuid type), MySQL 8+ (UUID()), every major language, every ORM, and the URL specification.

ULID (Universally Unique Lexicographically Sortable Identifier)

A 26-character Crockford Base32 string: 10 characters of millisecond timestamp followed by 16 characters of randomness. ULIDs sort by creation time when sorted lexically, which makes them an excellent primary key, you get UUID-style uniqueness AND chronological ordering in the same column without a separate created_at index.

Use ULIDs when you want time-ordered IDs (audit logs, event streams, append-only tables) without the database performance hit of fully random UUIDs in B-tree indexes.

Nano ID

A 21-character URL-safe ID drawn from a 64-character alphabet (A-Za-z0-9_-). Shorter than a UUID, slightly less collision-resistant (126 bits vs UUID's 122 effective bits, practically the same), and considerably more readable in URLs. Popular in JavaScript/TypeScript projects and any context where you'll be sharing the ID in a query string or path segment.

How to use it

1. Pick the format, UUID v4, ULID, or Nano ID, using the segmented control in the toolbar. 2. Set the count (1–1,000). Bulk generation is for seeding test data, populating a CSV, or stress-testing a schema. 3. Pick the case, lowercase or UPPERCASE. UUID v4 lowercase is the canonical RFC form; uppercase is required by some legacy Microsoft systems and a few Java libraries. 4. Click Generate (or hit ⌘↵ / Ctrl+Enter from anywhere on the page). 5. Copy the entire batch with the copy button or Download as a .txt file with one ID per line.

How collision-safe are these IDs?

For UUID v4 with 122 bits of randomness, you'd need to generate around 2.7 quintillion (≈2.7 × 10¹⁸) IDs to reach a 50 % chance of one collision, the "birthday paradox" applied to a 2¹²² space. In practice, every popular platform (databases, message queues, CDN cache keys) treats UUID v4 as effectively unique without coordination.

ULIDs add a millisecond timestamp prefix, which doesn't reduce randomness, the trailing 80 random bits are still drawn fresh per call, even within the same millisecond. Within a single millisecond on a single machine, an 80-bit random space is more than enough to avoid local collisions.

Nano ID's 126 bits are technically slightly stronger than UUID v4's 122. The shorter visual length comes from a denser alphabet, not less entropy.

Common gotchas

  • Never use Math.random() for IDs that touch security. This tool uses crypto.getRandomValues() everywhere, predictable, seedable PRNGs are fine for game logic and animation, never for tokens, session IDs, or anything you'll trust as unique.
  • UUID v4 in a B-tree index is slow on writes. The randomness defeats locality, every insert lands in a different leaf page. ULID or a time-prefixed UUID variant (UUIDv7) avoids the issue.
  • UUID storage type matters. Storing UUIDs as VARCHAR(36) instead of a native UUID column triples storage and slows comparisons. Use the native type whenever your database offers one (Postgres, modern MySQL, SQL Server, SQLite via blob).
  • Don't rely on UUID v4 to be sortable, ever. They're random, neighbouring UUIDs in your output have no temporal relationship. If you need order, use ULID.

Privacy

All IDs are generated locally in your browser using crypto.getRandomValues, the same cryptographic RNG your browser uses for HTTPS handshakes. No IDs are sent to a server, no batch is logged, no telemetry is recorded against the values themselves, the tool is genuinely a one-shot local generator.

Frequently asked

Are these IDs cryptographically secure?

Yes. Every byte of randomness is drawn from crypto.getRandomValues, the browser's CSPRNG — the same source used for HTTPS handshakes. No Math.random anywhere. Safe to use the output as session tokens, API keys, idempotency keys, or anything else that must be unpredictable.

Are the IDs sent to a server?

No. Generation happens entirely in your browser. The tool never uploads, logs, or persists the IDs it produces. Bulk-generated batches stay on your machine until you copy or download them.

What's the difference between UUID v4, ULID, and Nano ID?

UUID v4 is the RFC 4122 standard — 36 characters with hyphens, 122 bits of randomness, no ordering. ULID is 26 characters with a millisecond timestamp prefix, so it sorts chronologically when sorted lexically. Nano ID is 21 characters from a URL-safe alphabet — shortest of the three, equivalent entropy to UUID v4.

Why would I pick ULID over UUID v4?

ULIDs sort by creation time when sorted as strings, which makes them an excellent primary key for append-only tables (events, audit logs, analytics). You get UUID-grade uniqueness AND chronological ordering in one column, without a separate created_at index. UUIDs are random, so insert performance into B-tree indexes is worse.

Is bulk generating 1,000 IDs at once safe?

Yes. The browser CSPRNG produces independent random bytes per call, so 1,000 IDs generated in a tight loop are no more correlated than 1,000 generated over a week. Collision probability with UUID v4 is negligible at any practical batch size — you'd need quintillions of IDs to reach a 50% collision chance.

When should I pick UPPERCASE over lowercase?

Lowercase is the canonical RFC 4122 form for UUIDs and what virtually all modern systems expect. Use UPPERCASE only when interfacing with legacy Microsoft/COM systems, certain Java libraries, or vendor APIs that explicitly require it. ULIDs are always uppercase by spec; the lowercase option here is for consistency with surrounding lowercase IDs.

Can I validate an existing UUID or ULID with this tool?

Yes — the tool accepts existing IDs and tells you whether they parse as a valid UUID or ULID, including the version field for UUIDs. Useful for sanity-checking IDs received from an external API or pasted from a log.

Is UUID v4 ever a bad choice for a primary key?

If your write throughput is high and you store UUIDs in a B-tree index, yes — every insert lands in a random leaf page, which thrashes the cache and fragments the index. Use ULID, UUID v7, or another time-ordered variant for high-write tables. For low-to-moderate write rates, UUID v4 is perfectly fine.

Related tools