The Structure of UUID v4 – 122 Random Bits
Every UUID v4 is a 36-character string in the standard 8‑4‑4‑4‑12 hex format: eight hex digits, a hyphen, four hex digits, a hyphen, four hex digits, a hyphen, four hex digits, a hyphen, twelve hex digits. This canonical representation is defined by RFC 4122. Of those 128 bits, exactly 122 are generated from strong random sources. The remaining six bits are fixed: four bits identify the variant (binary 10xx for the usual variant 1) and two bits identify the version (0100 for version 4). The tool on this page exposes two format-specific toggles that directly affect this string: Uppercase and Include hyphens. When uppercase is on, the hex letters a–f are displayed as A–F. When hyphens are omitted, the output becomes a 32-character hex string. Both changes are purely cosmetic; the underlying 122 random bits remain identical. Because the randomness is generated in the browser via crypto.randomUUID() or equivalent APIs, every ID produced is independent and uniformly distributed across the 2¹²² possible values.
Collision Probability and Why It Matters
The fundamental guarantee of any UUID v4 generator is that duplicates are astronomically unlikely for practical workloads. With 122 bits of entropy, the probability of a collision among n randomly generated IDs follows the well-known birthday problem formula:
p ≈ 1 - e^(-n² / (2 × 2¹²²))
For 1 trillion IDs (n = 10¹²), the collision probability is roughly 1.5 × 10⁻⁶ – about 1.5 in a million. For 100 billion IDs, it drops to 1.5 × 10⁻¹⁰. In everyday use – generating a few thousand IDs for application objects – the probability is effectively zero. This property makes UUID v4 ideal for distributed systems where central coordination is impossible: devices in different datacenters, mobile clients offline, or microservices that need to assign unique keys without a round trip to a database. The trade-off is that unlike time-based identifiers (UUID v7, ULID, Snowflake), there is no inherent ordering. That lack of ordering becomes the next important topic.
Impact on Database Indexing – The Randomness Trade-off
Because UUID v4 values sort arbitrarily, they make poor primary keys for most relational databases that use B‑tree indexes. Every insertion of a new UUID v4 will land at a random position in the index, causing frequent page splits and index fragmentation. The result is degraded write performance, increased storage overhead, and slower range scans. In contrast, time-based identifiers like UUID v7, ULID, or auto-increment integers insert new rows at the end of the index, keeping the tree balanced and reducing I/O. UUID v4 values sort arbitrarily – they carry no time or ordering information, so using them as a primary key fragments B‑tree indexes. This is not a bug but a design consequence. UUID v4 is chosen precisely when ordering is undesirable – for example, when you want to hide record counts from an API, prevent enumeration attacks, or work in environments where generating globally unique IDs without central coordination matters more than write throughput.
When to Choose UUID v4 Over Other Identifier Formats
On this tool, the dropdown alongside UUID v4 also offers UUID v7, ULID, and NanoID. Each serves a different purpose. UUID v4 is the right choice when:
- You need unguessable identifiers. Security engineers use v4 for API tokens, session IDs, event IDs, and other secrets where time-based correlation could leak information. Because the bits are pure randomness, no two generated values reveal anything about the order or approximate time of creation.
- Your system operates offline or without a central authority. A mobile app generating UUIDs for local data can later sync to a server without collision risk. Distributed microservices can assign identifiers independently.
- You want to prevent enumeration of resources. Unlike auto-increment integers, a UUID v4 gives an attacker no way to guess valid IDs by iterating through a range.
- You are populating test data with realistic, unique values. Database testers often generate hundreds of thousands of random UUIDs to simulate production load.
By contrast, UUID v7 (time-ordered) or ULID (sortable, URL-safe) are better for high-throughput write-heavy databases where indexing performance matters. NanoID offers shorter, URL-safe identifiers but sacrifices absolute uniqueness guarantees (21 characters with 64 bits of entropy by default). The page’s toggles (uppercase, hyphens) are specific to UUID formats v4 and v7; other types use different controls because their specification differs.
Customising the Format – Hyphens and Uppercase
Two toggles let you adjust how the UUID string looks. Include hyphens is on by default. When turned off, the output becomes a continuous 32-character hex string. This is useful for contexts where hyphens are not allowed – for example, in some file names, database column constraints that strip hyphens, or URL parameters where extra characters look messy. However, dropping hyphens removes the visual grouping that makes UUIDs human-parsable and can cause confusion when sharing IDs verbally. Uppercase displays hex letters A–F rather than a–f. Some legacy systems treat hex case insensitively; others are case-sensitive and require a specific case. The tool regenerates immediately when either toggle is switched, because the change affects the output string even though the underlying bits are unchanged. These toggles are only relevant to UUIDs (v4 and v7); other ID types on the tool use different controls.
How Generation Works – Local Browser Randomness
All identifier generation on this page happens entirely in the user’s browser. No data is sent to a server. This is achieved using crypto.randomUUID() (where available) or a fallback that reads from crypto.getRandomValues(). The browser’s cryptographically strong random number generator is seeded from system entropy sources (hardware noise, timing jitter) that meet the requirements for secure random generation. The benefits are threefold:
- Privacy: no one else sees the IDs you generate.
- Latency: results appear instantly, even when generating 100 UUIDs at once.
- Offline capability: once the page loads, further network access is unnecessary.
The count input accepts values from 1 to 100 inclusive. Changing count, format, or any toggle immediately triggers regeneration and clears the previous list. After generation, you can copy a single ID by clicking it, or copy all IDs at once with a single button – the page shows “Copied all!” momentarily. A status line reads “Ready.” before any action and “Generated.” after a generation occurs.
FAQ
Q: What is the exact probability of two UUID v4s colliding?
For 122 bits of entropy, the probability of at least one collision among n IDs is approximately 1 - e^(-n² / (2 · 2¹²²)). For 1,000 IDs it’s about 1.2 × 10⁻³³. You can safely assume no collision for any realistic dataset.
Q: Why shouldn’t I use UUID v4 as a primary key in a large database?
Because random insertions cause B-tree index fragmentation and frequent page splits, degrading write performance and increasing storage. If the database must handle millions of writes per second, time-ordered IDs (like UUID v7 or ULID) are more suitable.
Q: Can I generate IDs without hyphens?
Yes. Toggle “Include hyphens” off. The output becomes a 32-character hex string. The underlying randomness and uniqueness properties are unchanged.
Q: Does this tool work offline?
After the page loads, yes. All generation occurs in the browser using JavaScript’s crypto API. No data is sent over the network.
Q: Why does the page regenerate IDs immediately when I change any setting?
The tool ensures that the displayed IDs always match the current options. Changing count, format, uppercase, or hyphens triggers a fresh batch of random IDs so the output is consistent with the chosen parameters.
Q: How many UUIDs can I generate at once?
Between 1 and 100 inclusive. The count input enforces this range. For larger batches, you can generate multiple times and combine results.