~/uuid-generator

UUID Generator

Generate UUIDs in v4 (random), v7 (time-ordered), or NIL form. Bulk export up to 1,000 at once. Cryptographically secure randomness, all in your browser.

count
generated · v40 uuids
random (122 bits of entropy)format: RFC 4122 / RFC 9562
// how to use

Generate UUIDs in two clicks.

  1. 01Pick the UUID version.v4 for random IDs (most common). v7 for time-ordered IDs (better for database keys). NIL for the all-zeros placeholder.
  2. 02Set how many you need.One by default, up to 1,000 at a time. Useful for seeding databases, generating test data, or producing batches of idempotency keys.
  3. 03Copy or download.Click any single UUID to copy it. Use “copy all” for the full list, or “.txt” to download as a newline-separated file.
// background

What is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit number designed to be unique across space and time without requiring a central authority. It's formatted as 32 hexadecimal characters in 5 groups separated by hyphens, like 550e8400-e29b-41d4-a716-446655440000.

The original spec (RFC 4122) defined versions 1 through 5. Version 4 — fully random — became the most common because of its simplicity and excellent uniqueness properties. The updated RFC 9562 added versions 6, 7, and 8, with v7 emerging as the new recommended default for database primary keys.

UUID versions explained

v1Time + MAC addressMostly deprecated, leaks host info
v3MD5 hash of namespace + nameDeterministic, niche
v4Fully randomMost common, no temporal info
v5SHA-1 hash of namespace + nameDeterministic, like v3 but stronger
v7Unix ms timestamp + randomTime-ordered, ideal for DB keys

Why use v7 for database primary keys

When you insert random v4 UUIDs as primary keys into a B-tree index, every new row lands at a random position, causing frequent page splits and poor cache locality. v7 IDs are time-ordered: each new row appends to the end of the index, keeping it dense and fast. You get the uncoordinated-uniqueness of UUIDs and the insertion performance of auto-incrementing IDs.

Common uses

  • Primary keys in distributed databases
  • Idempotency keys for API requests
  • Session tokens and request IDs for tracing
  • Filenames for uploaded content (avoid collisions)
  • Correlation IDs across microservices
  • Public-facing IDs that don't leak row counts
// faq

Frequently asked questions.

What's the difference between UUID v4 and v7?+
v4 is fully random — 122 bits of entropy with effectively zero collision probability. v7 is time-ordered: the first 48 bits are a Unix millisecond timestamp, the rest is random. v7 sorts naturally by creation time, which makes it ideal for database primary keys (better index locality, less page splitting).
Is UUID v7 standardized? Should I use it in production?+
Yes, v7 is part of RFC 9562 (May 2024), which obsoletes the older RFC 4122. It's officially standardized and supported by major libraries. Postgres, MySQL, and most ORMs handle v7 natively. Use it whenever you'd previously have used v4 in a database — better performance with no downsides.
Can two UUIDs collide?+
In theory yes, in practice never. A v4 UUID has 122 random bits, giving 2^122 possible values (around 5.3 × 10^36). To have a 50% chance of collision you'd need to generate billions of UUIDs per second for tens of years. For all real-world purposes, treat them as guaranteed unique.
How is the randomness generated here?+
The tool uses the browser's crypto.randomUUID() and crypto.getRandomValues() APIs, which are cryptographically secure pseudo-random generators (CSPRNG). This is the same source of randomness used by browser-based encryption, much stronger than Math.random().
What is the NIL UUID?+
It's the special value 00000000-0000-0000-0000-000000000000, all zeros. It's defined by the RFC as a placeholder meaning 'no UUID set'. Useful for default values or to represent the absence of an ID without using null.
How are UUIDs different from auto-incrementing IDs?+
Auto-incrementing IDs (1, 2, 3...) are short and human-readable but expose row count, are predictable (security concern), and require a single coordinator to assign them. UUIDs can be generated independently on any machine with no coordination, are non-guessable, and don't leak information about table size — at the cost of being longer and slightly slower as primary keys.