UUID Generator

What is a UUID / GUID and Which Version Should You Use?

A standard canonical UUID consists of 32 hexadecimal digits separated by hyphens into five distinct groups in an 8-4-4-4-12 pattern (e.g. f47ac10b-58cc-4372-a567-0e02b2c3d479), representing exactly 128 bits (16 bytes) of information. Because modern cloud-native systems generate millions of concurrent transactional records across geographically dispersed microservices, UUIDs allow distributed worker nodes to allocate unique primary keys independently without central synchronization or locking bottlenecks.

RFC 4122 & RFC 9562 UUID Versions Comparison

Anatomy of a 128-Bit Identifier: Version Nibbles and Variant Bits

Every RFC-compliant UUID reserves six specific bits to identify its internal layout and construction rules, leaving 122 bits available for entropy or timestamp data:

• Version Nibble (Bits 48-51): The four most significant bits of the third group (time_hi_and_version) declare the algorithm version. In hexadecimal representation, the first character of this group indicates the version: 4 for random v4 (e.g. ...-4xxx-...) or 7 for epoch-timestamped v7 (e.g. ...-7xxx-...).
• Variant Bits (Bits 64-65): The two most significant bits of the fourth group declare the layout variant. In standard RFC 4122 and RFC 9562 identifiers, these bits are fixed to binary 10. In hexadecimal, this causes the first digit of the fourth group to always be one of four values: 8, 9, a, or b.

The Database Indexing Crisis: B-Tree Fragmentation and Why UUID v7 Wins

For two decades, database administrators wrestled with the performance penalties of using random UUID v4 values as primary keys in relational database management systems like PostgreSQL, MySQL (InnoDB), and Microsoft SQL Server. Because standard relational tables store data inside clustered B-tree indexes ordered by primary key:

• Random Page Splits: UUID v4 values distribute uniformly across the entire 128-bit address space. When new rows arrive, they land randomly across arbitrary memory pages. When a target leaf page is full, the database engine must split the page into two, rewrite surrounding parent pointers, and flush dirtied memory pages to disk.
• Buffer Cache Exhaustion: As database tables grow into millions of rows, the clustered index exceeds available RAM. Because inserts are completely scattered, almost every single insert triggers a slow physical disk read to pull a cold index page into cache.
• The UUID v7 Remedy: Standardized in RFC 9562, UUID v7 encodes a 48-bit Unix millisecond epoch timestamp in the highest bits. Because time flows forward monotonically, newly generated UUID v7 keys sort naturally in chronological order. Inserts consistently append to the rightmost leaf of the B-tree index, eliminating mid-tree page splits, preserving cache locality, and providing write speeds virtually indistinguishable from sequential 64-bit auto-incrementing integers.

The Birthday Paradox and Collision Probability at Scale

A common apprehension among engineers evaluating UUID v4 is the theoretical risk of two systems generating identical identifiers. With 122 bits of true entropy, the total keyspace contains:

2¹²² ≈ 5.316 × 10³⁶ unique identifiers

Using the mathematical approximation of the Birthday Problem, the probability p of at least one collision after generating n random identifiers is approximately p ≈ n2 / (2 × 2122). To reach a 50 percent probability of experiencing a single collision, a system would have to generate approximately 2.71 quintillion (2.71 × 10¹⁸) UUIDs. If an enterprise generated 1 billion UUIDs every second without interruption, it would require over 85 years of sustained throughput to reach a one-in-a-billion chance of a duplicate key.

Cryptographic Entropy: Why Web Crypto CSPRNG Outperforms Math.random()

Earlier web applications generated pseudo-random UUIDs using JavaScript's built-in Math.random(). This practice is severely dangerous in production: Math.random() relies on non-cryptographic PRNG algorithms (such as xorshift128+) designed purely for speed, not unpredictability. An attacker observing a sequence of identifiers can determine the internal state of the PRNG and forecast upcoming session tokens.

This generator strictly executes using the browser's hardware-backed Web Crypto API (crypto.getRandomValues() and native crypto.randomUUID()). The browser requests entropy directly from the underlying operating system kernel (such as /dev/urandom on Linux and macOS, or BCryptGenRandom on Windows), ensuring non-deterministic, cryptographically secure random distribution.

Cross-Platform Implementation Guide

Authoritative snippet references for generating standard UUID v4 and modern UUID v7 identifiers across production stacks:

Migration Strategies: Transitioning from UUID v4 to UUID v7

Engineering teams managing established production services often face the challenge of upgrading legacy schemas from random UUID v4 to monotonic UUID v7 without requiring invasive downtime or bulk data migrations:

• Schema-Level Native UUID Compatibility: In systems like PostgreSQL, CockroachDB, and SQLite, both v4 and v7 identifiers are stored inside identical 128-bit native UUID or BYTEA binary columns. Because the underlying storage datatype does not enforce version constraints, application servers can begin inserting UUID v7 primary keys into existing tables immediately without modifying existing table DDL schemas.
• Zero-Downtime Dual Generation: New records automatically gain the insertion and cache locality benefits of UUID v7, while historical rows with v4 keys remain completely accessible and queryable by primary key. Foreign key constraints across relational tables operate reliably across mixed versions.
• Index Optimization: Over time, as new transactional records cluster naturally at the end of the B-tree leaf nodes, write amplification drops significantly. If historical tables suffer from existing index fragmentation, running an online index rebuild (such as REINDEX TABLE CONCURRENTLY in PostgreSQL or OPTIMIZE TABLE in MySQL InnoDB) consolidates storage pages and recovers wasted buffer pool memory.

Formatting Options and Zero-Trust Client Privacy

Different application protocols require tailored string representations. This tool provides instant toggles for uppercase characters (standard in Microsoft GUID and Windows registry keys) and hyphen removal (creating compact 32-character hexadecimal strings frequently used in MongoDB ObjectIds and URL path parameters). In addition, the built-in live inspector extracts the internal version, variant, and exact UTC creation timestamp from any pasted UUID v7 or v1 string.

Security and data isolation are strictly preserved: all random bit collection, timestamp concatenation, hex formatting, and file export operations execute entirely within your client browser. No generated tokens, identifiers, or pasted inputs are ever transmitted over the network or saved on remote servers.