UUID Generator

UUID Standards and Distributed Identity

The Universally Unique Identifier was first standardized in RFC 4122 (2005), though its roots trace back to Apollo Network Computing System in the 1980s and the Open Software Foundation's Distributed Computing Environment (DCE). The fundamental problem UUIDs solve is generating globally unique identifiers without a central coordination authority — essential for distributed systems where multiple machines must independently create IDs that will never collide. RFC 4122 defined five UUID versions, each addressing different use cases. Version 1 embeds a 60-bit timestamp (100-nanosecond intervals since October 15, 1582 — the Gregorian calendar reform) combined with a 48-bit node identifier originally derived from the network card's MAC address. While guaranteeing uniqueness, v1 leaked hardware identity and creation time, raising privacy concerns. Version 3 and Version 5 are name-based: they hash a namespace identifier combined with a name using MD5 (v3) or SHA-1 (v5), producing deterministic UUIDs where the same input always yields the same output. Version 4 replaced determinism with 122 bits of cryptographic randomness, becoming the most widely adopted version. The newest standard, RFC 9562 (2024), introduced UUID v7 as the recommended choice for database-friendly identifiers. Version 7 embeds a 48-bit Unix millisecond timestamp in the most significant bits, followed by random fill bits. This design creates identifiers that sort chronologically when compared as strings or bytes — a critical advantage for B-tree database indexes where random v4 UUIDs cause excessive page splits and fragmentation. Benchmarks consistently show that v7 UUIDs improve database insert throughput by 20-40% compared to v4 in large tables. The collision probability of UUID v4 is governed by the birthday paradox. With 122 random bits, the space contains 5.3 x 10^36 possible values. The probability of generating a duplicate reaches 50% only after producing approximately 2.71 x 10^18 UUIDs — equivalent to generating one billion per second for over 85 years. Competing identifier formats include Twitter's Snowflake IDs (64-bit, datacenter-aware), ULIDs (128-bit with Crockford Base32 encoding for sortability), NanoIDs (compact URL-safe strings), and database auto-increment sequences. Each involves tradeoffs between uniqueness guarantees, sortability, storage size, and coordination requirements.

Methodology

UUID v4 generation relies on the browser's crypto.randomUUID() method from the Web Crypto API, which produces 128 bits where 122 are cryptographically random and 6 are reserved for version (4 bits set to 0100) and variant (2 bits set to 10) markers. This ensures every UUID is self-describing — you can identify its version by inspecting the 13th hexadecimal character. UUID v7 embeds a 48-bit Unix timestamp in milliseconds in the most significant bits, followed by random fill bits. This design produces identifiers that are both unique and naturally time-ordered, making them ideal for database primary keys where B-tree index performance matters. UUID v1 uses a 60-bit timestamp at 100-nanosecond resolution since October 15, 1582 (the Gregorian calendar reform date), a 14-bit clock sequence to prevent duplicates on clock adjustments, and a 48-bit node identifier generated randomly for privacy protection. ULIDs encode a 48-bit millisecond timestamp followed by 80 random bits, rendered in Crockford Base32 for compact, case-insensitive representation. NanoIDs use a configurable alphabet and length, defaulting to 21 characters from a URL-safe set, providing 126 bits of entropy.

Understanding Your Results

Each UUID is a 128-bit value displayed as 32 hexadecimal characters in 5 groups separated by hyphens, following the pattern 8-4-4-4-12. The canonical format is xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx, where the M position (13th hex character) indicates the version and the N position (17th hex character) indicates the variant. For UUID v4, M is always '4' and N is one of '8', '9', 'a', or 'b', confirming RFC 4122 compliance. For UUID v7, M is '7' and the first 12 hex characters encode the millisecond timestamp, making the creation time directly readable. UUID v1 places M as '1' with the timestamp split across the first three groups in a rearranged order. ULIDs are displayed as 26 uppercase Crockford Base32 characters — the first 10 encode the timestamp and the remaining 16 encode randomness. NanoIDs appear as compact strings using URL-safe characters (A-Z, a-z, 0-9, hyphen, underscore), with no inherent structural markers. When choosing a format, consider that UUIDs with braces are common in Microsoft ecosystems, while dashless UUIDs save storage in databases.

Practical Examples

Database primary keys: Use UUID v7 for PostgreSQL or MySQL tables where insert order matters. The embedded timestamp ensures sequential key values, avoiding random I/O scatter that UUID v4 causes on clustered indexes. Microservice event tracking: Generate UUID v4 for correlation IDs passed through message queues (Kafka, RabbitMQ). The pure randomness guarantees no collisions even when thousands of services produce IDs simultaneously. Frontend session tokens: Use NanoID for compact, URL-safe session identifiers in single-page applications. At 21 characters, they are shorter than UUIDs while maintaining equivalent collision resistance. File naming and deduplication: Generate ULIDs for uploaded file identifiers. Their lexicographic sortability means a simple alphabetical listing shows files in chronological upload order.

Tips & Best Practices

Choose your UUID version based on your use case rather than defaulting to v4. If your identifiers will serve as database primary keys, UUID v7 or ULID provide significantly better insert performance because their time-ordered nature keeps B-tree indexes sequential, reducing page splits and fragmentation. For distributed systems where multiple nodes generate IDs independently, UUID v4's pure randomness eliminates any risk of timestamp-based collisions. When working with URLs or user-facing identifiers, NanoID's compact 21-character format is more practical than a 36-character UUID. Always store UUIDs as their native 128-bit binary type in databases when available (e.g., PostgreSQL's uuid type or MySQL's BINARY(16)) rather than as VARCHAR(36) strings. This cuts storage by more than half and improves comparison performance. When debugging, remember that the version digit (position 13) instantly tells you which UUID variant you are looking at.

Sources

• RFC 4122 – UUID Specification
• MDN – Crypto.randomUUID()