UUID Generator

Generates universally unique identifiers (UUIDs) in version 4 (random) or version 7 (timestamp-prefixed) format. Output may be lowercase, uppercase, with or without hyphens, and in batches of up to 1000. UUIDs follow the RFC 9562 standard.

Version 4 produces 122 bits of randomness, sufficient that collision is statistically impossible at any realistic scale. Version 7 embeds a millisecond timestamp in the high bits, making the IDs sortable while preserving uniqueness.

The UUID format is 128 bits, displayed as 32 hexadecimal characters in five groups separated by hyphens: 8-4-4-4-12. Version 4 places 122 random bits with 6 fixed bits identifying the variant and version. Version 7, finalized in RFC 9562 (May 2024), uses 48 bits for a Unix millisecond timestamp followed by 74 random bits, producing IDs that are both unique and sortable in creation order.

The collision probability calculation is illuminating. For v4 UUIDs, the birthday paradox gives a 50% collision probability after generating roughly 2^61 = 2.3 × 10^18 UUIDs. At a billion UUIDs per second, this takes 73 years. Real systems do not encounter v4 collisions outside deliberate testing. The probability of any individual collision in a database of one billion v4 UUIDs is roughly 1 in 2^62 — vanishingly small.

Version 7's design addresses a real database performance problem. Random v4 UUIDs as primary keys scatter writes across a B-tree index, causing index fragmentation and poor write throughput. Each insert lands in a random index page, requiring page loads and writes throughout the index. v7 UUIDs sort by creation time, so consecutive inserts land in adjacent index pages — locality similar to auto-incrementing integer keys without the auto-increment coordination overhead. PostgreSQL benchmarks show 3-10× write throughput improvement on large tables when migrating from v4 to v7.

A worked example. v4 UUID: 6ba7b810-9dad-11d1-80b4-00c04fd430c8 (the actual format; this specific value is a v1 example from RFC 4122). v7 UUID: 0188-7d6e-1c5b-7000-9d77-1b6c4f6f3e2a (timestamp 2023-12-04 visible in first 12 hex chars). Sorting v4 UUIDs lexicographically produces random order; sorting v7 UUIDs lexicographically matches creation order to millisecond resolution.

Adjacent identifier formats provide similar properties. ULID (Universally Unique Lexicographically Sortable Identifier) predates v7 with a 26-character base32 encoding and similar sortable-by-time semantics. KSUID uses 32-bit timestamps and 128 bits of random data in 27 base62 characters. NanoID provides shorter random IDs (default 21 chars, customizable alphabet) at the cost of standard format. The choice depends on context: v7 UUID for compatibility with existing UUID infrastructure; ULID/KSUID for cleaner string representation; NanoID for URL-friendly short IDs.

Limitations: v7 UUIDs reveal creation time, which is sometimes a privacy or security concern. An attacker observing a v7 ID can determine when the corresponding record was created to millisecond resolution. For public-facing IDs where creation time should be opaque, v4 remains preferable. The timestamp visibility is a feature for internal databases and a bug for some external interfaces.