Generate unique UUIDs (v4 and v7) in bulk. Copy single keys or export lists of unique identifiers.
A UUID (Universally Unique Identifier) is a 128-bit label used to uniquely identify objects in distributed computer systems. Standardized in RFC 4122, UUIDs are formatted as 32 hexadecimal digits arranged in 5 groups separated by hyphens: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx. The M digit indicates the UUID version and the N digit indicates the variant — most modern UUIDs use version 4 (random) and variant 10 (binary).
This generator produces RFC 4122 compliant UUIDs using the browser's cryptographically secure random number generator (crypto.getRandomValues). All generation is client-side — no UUID data is transmitted to any server. Generate one at a time or produce bulk lists for database seeding, test fixture generation, and ID pool pre-allocation.
UUID v1 encodes a timestamp (nanoseconds since October 1582) combined with a machine node identifier (MAC address or random). V1 UUIDs sort chronologically but reveal the generating machine's MAC address and creation time — a privacy concern. UUID v4 uses 122 random bits (with 6 bits reserved for version/variant), producing statistically collision-resistant identifiers with no embedded information — the preferred choice for most applications.
UUID v5 generates deterministic UUIDs from a namespace UUID and a name string using SHA-1 hashing — the same input always produces the same UUID. This makes v5 appropriate for deriving stable identifiers from natural keys (URLs, email addresses) in a collision-resistant way. UUID v7 (RFC 9562, 2024) uses a Unix millisecond timestamp prefix for sortability combined with random bits — improving on v1's timestamp encoding while preserving natural chronological ordering. V7 is increasingly recommended for database primary keys.
UUID v4 collision probability is astronomically low. With 122 random bits, there are 2^122 ≈ 5.3 × 10^36 possible UUIDs. The birthday paradox tells us that generating 1 billion UUIDs per second for 85 years would give approximately a 50% chance of ONE collision. For any practical application, UUID v4 is effectively collision-free.
Modern database systems (PostgreSQL, MySQL 8, SQL Server, SQLite) store UUIDs either as 36-character strings, 32-character hex strings (without hyphens), or native 16-byte binary types. Binary storage is significantly more efficient for indexing — a 16-byte binary UUID index is smaller and faster than a 36-character string index. UUID v7's monotonically increasing timestamp prefix also prevents index fragmentation in B-tree indexes, unlike the purely random v4.
UUID v4 uses 122 cryptographically random bits (6 bits are fixed for version/variant encoding). Its appeal is simplicity and privacy: no timestamp exposure, no machine identity leakage, no namespace configuration required. The near-zero collision probability (1 in 5.3×10^36 chance per pair) makes it practical for all use cases. V4 is supported universally across all programming languages, databases, and platforms.
UUID v7 is increasingly recommended for database primary keys over v4 because its timestamp prefix (millisecond Unix time) makes UUIDs monotonically increasing within the same millisecond, preserving insert order. This prevents B-tree index fragmentation — a major performance problem with random v4 UUIDs on write-heavy tables. UUID v7 provides the same uniqueness guarantees as v4 with significantly better database performance characteristics.
UUID v4 uniqueness is probabilistic, not absolute, but the collision probability is negligible for any practical application. With 2^122 possible values, generating 1 billion UUIDs per second for 85 years yields approximately 50% chance of a single collision. In practice, you would exhaust disk space and computational resources long before approaching collision probability. For most purposes, UUID v4 is indistinguishable from guaranteed uniqueness.
The nil UUID is a special UUID with all 128 bits set to zero: 00000000-0000-0000-0000-000000000000. It is used as a sentinel value or null placeholder in systems where a UUID is structurally required but the value is intentionally absent or unset. Similar to null in SQL or None in Python — it represents the absence of a real UUID identifier. RFC 9562 also defines a max UUID (all bits set to 1): ffffffff-ffff-ffff-ffff-ffffffffffff.
Yes. UUIDs are fundamentally 128-bit (16-byte) binary values. The hex string format (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) is just a display convention. Convert to binary by removing hyphens and interpreting as 32 hex characters = 16 bytes. Most programming languages provide UUID libraries that handle this transparently: uuid.bytes in Python, UUID.fromString() and toByteArray() in Kotlin.