› UUID Generator

Generate v1, v4, or v7 UUIDs for databases, distributed systems and APIs.

// status READY
// transport localhost · 0 bytes uploaded
// id 0x4FEF
uuid-generator.sh 0x4FEF
# uuid-generator.md

Why Auto-Increment IDs Break Down in Distributed Systems

Auto-increment integers work perfectly as long as a single database instance owns the counter. The moment you introduce a second write node — a read replica promoted to primary during failover, a second region for disaster recovery, or a sharded database where rows land on different nodes — you lose your coordination point. Two nodes can both issue ID=10001 for different rows, and the collision only surfaces when data is merged or replicated. UUIDs solve this by generating identifiers that are statistically unique without any coordination: any node can generate one at any time, and the probability of a collision across all identifiers ever generated in the history of computing remains astronomically low.

The 128-bit space contains 2128 ≈ 3.4 × 1038 possible values. UUID v4 uses 122 bits of randomness (6 bits encode the version and variant). To reach a 50% collision probability, you would need to generate roughly 2.71 × 1018 UUIDs — at one billion UUIDs per second, that takes 86 years. The birthday paradox math is already in your favor at any realistic application scale.

The Three UUID Versions and When to Use Each

UUID v4 (pure random) is the default for most situations: 122 bits of cryptographic randomness from crypto.getRandomValues. No information is leaked about when, where, or by whom it was generated. The tradeoff is database index performance: because v4 UUIDs are uniformly distributed across the entire 128-bit range, sequential inserts scatter across a B-tree index, causing page splits and cache misses. On tables beyond a few million rows this becomes measurable.

UUID v7 (timestamp-ordered random) encodes a 48-bit Unix millisecond timestamp in the most-significant bits, followed by 74 bits of randomness. Because the timestamp prefix increases monotonically, new UUIDs sort to the end of a B-tree index rather than being scattered throughout — the same sequential-insert behavior as auto-increment, but without a coordination point. PostgreSQL 17+ has native UUID v7 support; most ORM libraries added it in 2023–2024. For any new database schema that will grow beyond a hundred thousand rows, v7 is the better choice for primary keys.

UUID v1 (timestamp + MAC address) is the original version from RFC 4122 (2005). It encodes a 60-bit timestamp with 100-nanosecond precision and the MAC address of the generating machine. This creates a privacy problem (your network hardware fingerprint is embedded in every generated ID) and a correlation problem (adversaries can infer when IDs were generated and from which machine). v1 is preserved for legacy compatibility only; use v7 if you need the timestamp-ordered property.

UUID vs. ULID vs. KSUID

The need for sortable unique identifiers produced several non-UUID formats. ULID (Universally Unique Lexicographically Sortable Identifier) encodes the same 48-bit millisecond timestamp as UUID v7 but uses Crockford base32 encoding, making it 26 characters rather than 36 — shorter for URL use. KSUID uses a 32-bit second-precision timestamp plus 128 bits of randomness, producing longer identifiers but with a 135-year epoch before overflow. UUID v7 is now the RFC-standardized equivalent of these; for new projects, v7 is the interoperable choice.

How to Use This Tool

  1. Pick the version: v4 (pure random, general use) or v7 (timestamp-ordered, database primary keys) or v1 (legacy compatibility only).
  2. Set the quantity: generate 1 to 100 at once for batch use cases.
  3. Copy individual UUIDs with the inline button, or copy all with the bulk copy action.

## man uuid-generator

?> What is the actual collision probability for UUID v4?

For n generated UUIDs, the collision probability is approximately 1 − e^(−n²/2×2¹²²). Generating one billion UUIDs per second for an entire year produces about 3.15×10¹⁶ total UUIDs, giving a collision probability of around 2×10⁻⁹ — effectively zero at any foreseeable scale.

?> Why does UUID v7 improve database performance over v4?

B-tree indexes maintain sorted order. UUID v4 inserts arrive in random order across the entire key space, forcing the database to split index pages constantly and keeping a large working set hot in memory. UUID v7 inserts arrive near-monotonically (same as auto-increment), so new rows append to the right edge of the index and old pages cool down predictably. This reduces write amplification and improves cache hit rates.

?> Should I expose UUIDs to end users in URLs?

UUID v4 is safe to expose — it reveals nothing about the data. UUID v1 should not be exposed publicly because it embeds the server MAC address and exact generation timestamp, giving adversaries information they should not have. UUID v7 embeds a timestamp (millisecond precision) — generally acceptable but review your threat model.

?> Is UUID v7 an official standard?

Yes. RFC 9562 (May 2024) is the current UUID standard and formally defines UUID v7 alongside the original v1 and v4. It supersedes RFC 4122 from 2005. Major database engines and ORM libraries have added v7 support since 2023.