UUID Generator

Universally Unique Identifiers (UUIDs) provide collision-resistant primary keys and correlation IDs across distributed systems without a central coordinating authority. This free generator creates cryptographically secure RFC 4122 Version 4 random UUIDs, modern RFC 9562 Version 7 time-ordered identifiers for database indexing, and Version 1 timestamped records in bulk. Customize casing, hyphenation, code wrappers, and delimiters, or inspect any existing UUID to decode its version, variant, and embedded timestamp. Everything runs 100% in your browser using cryptographic entropy — no server calls, zero tracking.

What is a UUID? The Architecture of Universally Unique Identifiers

A Universally Unique Identifier (UUID), standardized under IETF RFC 4122, RFC 9562, and ITU-T Recommendation X.667, is a 128-bit label designed to provide collision-resistant identification across distributed computing systems. The primary architectural advantage of a UUID is decentralization: independent distributed nodes, microservices, mobile clients, and database shards can generate identifiers simultaneously without checking a centralized registration authority, pinging a database sequence generator, or coordinating over network locks.

In standard canonical textual representation, a UUID comprises 32 hexadecimal digits displayed in five hyphen-separated groups formatted as 8-4-4-4-12 (for example, 018f67e4-8a4b-76f2-a721-69429188d92e). This represents exactly 16 octets (128 bits). In the Microsoft ecosystem, these identifiers are commonly referred to as Globally Unique Identifiers (GUIDs), following identical 128-bit mathematical layouts with differing historical endianness and casing conventions.

RFC 4122 vs RFC 9562: The Modern Evolution to UUID v7

For nearly two decades, engineering teams relied predominantly on RFC 4122 Version 4 random UUIDs for database primary keys and API resource identifiers. However, as high-throughput transactional databases scaled into millions and billions of records, the fundamental limitation of UUID v4 emerged: total lack of temporal locality.

Because UUID v4 distributes random bits uniformly across its entire 128-bit address space, every newly inserted database record lands at an unpredictable location in the storage engine's B-Tree index. In databases such as PostgreSQL, MySQL (InnoDB), and SQLite, this causes severe index fragmentation, continuous B-Tree page splits, cache thrashing, and high write amplification. Memory pages containing index leaf nodes must be constantly swapped in and out of the database buffer pool, degrading insert performance by orders of magnitude once index sizes exceed available RAM.

To resolve this architectural defect, the Internet Engineering Task Force (IETF) ratified RFC 9562 in 2024, introducing UUID Version 7. Version 7 replaces the legacy timestamp layout with a 48-bit big-endian unsigned Unix Epoch timestamp with millisecond resolution in the most significant bits, followed by the 4-bit version field, a 12-bit fractional or random sub-millisecond counter, the 2-bit variant field, and 62 bits of cryptographic randomness. This produces a k-sortable identifier: records naturally sort chronologically at insertion time, preserving optimal B-Tree append locality while retaining 74 bits of uncoordinated cryptographic entropy.

Comparison of UUID Versions

Selecting the appropriate UUID variant depends on your system's data access patterns, indexing strategies, and privacy requirements. The following matrix details the operational characteristics across versions:

UUID Version	Standard	Primary Entropy Source	Monotonic Sorting	B-Tree Index Friendliness	Best Fit Use Case
Version 4 (Random)	RFC 4122	122 bits CSPRNG randomness	No (Completely random)	Poor (High page splits & fragmentation)	Session tokens, reset links, ephemeral keys
Version 7 (Unix Time)	RFC 9562	48-bit Unix ms + 74 bits CSPRNG	Yes (Millisecond k-sortable)	Excellent (Sequential index append)	Modern DB primary keys, event logs, SaaS entities
Version 1 (Gregorian)	RFC 4122	60-bit 100ns time + 48-bit Node	Partially (Time bits transposed)	Moderate	Legacy enterprise systems, Cassandra timeuuid
Version 3 (MD5 Name)	RFC 4122	Deterministic MD5 hash of namespace	No	Poor	Legacy deterministic URL/entity mapping
Version 5 (SHA-1 Name)	RFC 4122	Deterministic SHA-1 hash of namespace	No	Poor	Deterministic entity deduplication across clusters
Nil UUID	RFC 4122	Zero bits (all 128 bits set to 0)	N/A	N/A	Default unassigned sentinel in schemas & APIs

Mathematical Entropy and Collision Probabilities

A common operational concern when adopting decentralized identifiers is the mathematical probability of two independent nodes generating duplicate UUIDs (a collision). For Version 4 UUIDs, exactly 6 bits are reserved for structural metadata (4 bits defining version 0100 and 2 bits defining variant 10), leaving 122 bits of true entropy.

The total number of possible UUID v4 values is $2^{122} \approx 5.3 \times 10^{36}$ (5.3 undecillion combinations). Calculating the collision risk using the generalized Birthday Problem approximation:

$$p \approx 1 - \exp\left(-\frac{n^2}{2 \times 2^{122}}\right)$$

To achieve a minuscule one-in-a-billion ($10^{-9}$) chance of a single collision, a system must generate approximately $1.03 \times 10^{15}$ (over one quadrillion) UUIDs. If an application generated 10 million UUIDs every single second continuously for 100 years, the probability of encountering a duplicate remains less than $10^{-14}$.

For Version 7 UUIDs, 74 bits of cryptographic entropy are preserved alongside the 48-bit millisecond timestamp. Within any single millisecond window, the address space affords $2^{74} \approx 1.88 \times 10^{22}$ combinations, guaranteeing robust collision resistance even across massive distributed clusters generating millions of events per millisecond.

Database Storage Strategies: Native UUID vs BINARY(16) vs VARCHAR(36)

How UUIDs are physically stored on disk directly dictates query throughput, index cache footprint, and memory bandwidth:

• PostgreSQL (Native uuid Type): PostgreSQL natively stores UUIDs as packed 128-bit (16-byte) binary values, occupying exactly half the disk footprint of plain text representation. Index operations compare 64-bit word pairs directly in CPU registers.
• MySQL / MariaDB (BINARY(16)): While MySQL lacks a dedicated UUID keyword, storing identifiers as BINARY(16) combined with MySQL 8.0's native UUID_TO_BIN(..., 1) and BIN_TO_UUID(..., 1) functions enables compact 16-byte storage with automated timestamp transposition. Never store UUIDs as unindexed VARCHAR(36) in InnoDB tables, as this inflates clustered secondary indexes by 20 extra bytes per row.
• SQLite (BLOB vs TEXT): SQLite accommodates UUIDs as either 16-byte raw BLOB or 36-character TEXT. Using BLOB halves table size, though TEXT simplifies direct visual inspection during debugging.

UUID vs Alternative Identifier Formats

Modern engineering stacks frequently evaluate alternative decentralized identification schemes such as ULID, NanoID, and Snowflake IDs:

Identifier Format	Bit Size	Character Representation	Case Sensitivity	Time-Ordered	IETF Standardized
UUID v7	128 bits	36 chars (Hex with hyphens)	Case-insensitive	Yes (Millisecond)	Yes (RFC 9562)
UUID v4	128 bits	36 chars (Hex with hyphens)	Case-insensitive	No	Yes (RFC 4122)
ULID	128 bits	26 chars (Crockford Base32)	Case-insensitive	Yes (Millisecond)	No (Community spec)
NanoID	Configurable (126 bits default)	21 chars (URL-safe Base64)	Case-sensitive	No	No (Library spec)
Snowflake ID	64 bits	19 digits (Base10 integer)	Case-insensitive	Yes (Millisecond)	No (Twitter / Discord spec)

Frequently Asked Questions

Why does this generator use window.crypto instead of Math.random?

Standard Math.random() implementations in JavaScript engines use pseudo-random algorithms (such as xoshiro128+ or v8's XorShift128+) that are deterministic and not cryptographically secure. Their internal state can be reconstructed after observing a sequence of outputs, creating predictable ID generation vulnerabilities. In contrast, window.crypto.getRandomValues() interfaces directly with the host operating system's kernel entropy pool (such as Linux /dev/urandom, Windows CryptGenRandom / CNG, or macOS getentropy), providing true cryptographically secure pseudo-random numbers (CSPRNG) suitable for production security boundaries.

Can UUID v7 completely replace database auto-incrementing integer IDs?

Yes. UUID v7 combines the primary benefit of auto-incrementing integers (sequential B-Tree index append locality without page splits) with the primary benefit of UUIDs (decentralized, uncoordinated generation across multiple servers and offline clients). Furthermore, unlike auto-incrementing integer sequences (e.g. id=1042), UUID v7 does not leak business metrics such as total user count or order volume through URL enumeration attacks.

Are UUIDs case-sensitive?

According to RFC 4122 Section 3, UUIDs are explicitly defined as case-insensitive hexadecimal representations. Canonical output must be generated as lowercase. However, certain legacy environments — particularly Microsoft Windows registry keys, COM interfaces, and C# GUID string formatters — traditionally format identifiers in uppercase with curly brackets (e.g. {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}). This tool provides both lowercase and uppercase options to fit your language conventions.

How does UUID v1 handle MAC address privacy?

Historical RFC 4122 Version 1 implementations extracted the host machine's physical 48-bit IEEE 802 MAC address for the node identifier. This created severe privacy leaks, enabling network observers to identify the exact computer and network adapter that authored a document or database record. To eliminate this vulnerability, RFC 4122 Section 4.5 allows the node field to be populated with 48 cryptographically random bits, provided the multicast bit (least significant bit of the first octet) is set to 1. This generator strictly enforces the multicast privacy bit on all generated Version 1 records.

What is the difference between UUID and GUID?

In modern software engineering, GUID (Globally Unique Identifier) and UUID (Universally Unique Identifier) refer to the exact same 128-bit mathematical construct. GUID is the historical terminology coined by Microsoft in COM and Windows APIs, while UUID is the official IETF standard adopted across Unix, Linux, Java, Python, and web standards. Every valid GUID is a UUID conforming to RFC 4122 / RFC 9562.