What a UUID v4 actually is
A UUID (universally unique identifier) is a 128-bit number written as 32 hexadecimal digits in the familiar 8-4-4-4-12 pattern — 36 characters counting the hyphens. Version 4 is the random flavor: 4 bits encode the version, 2 encode the variant, and the remaining 122 bits come straight from a cryptographic random generator. That leaves two fingerprints you can spot by eye: the third group always starts with a 4, and the fourth with 8, 9, a or b.
The point is decentralization: any process on any machine can mint an ID with no coordination, no counter, no central authority — and still treat it as unique. That is why UUIDs show up as database primary keys, API resource IDs, object names in cloud storage, and trace IDs in distributed systems.
How to use this generator
- Set how many UUIDs you need, from 1 to 100.
- Pick lowercase (the canonical form) or UPPERCASE.
- Hit Generate — results appear instantly.
- Copy one UUID with the button next to it, or Copy all to grab the batch, one per line, ready for a script or seed file.
Everything runs locally through crypto.randomUUID(), backed by the operating system’s CSPRNG — nothing is uploaded anywhere.
Worked example: reading a UUID
Take the well-known sample UUID f47ac10b-58cc-4372-a567-0e02b2c3d479. The third group, 4372, starts with 4: the version marker for v4. The fourth group, a567, starts with a — 1010 in binary — whose leading 10 is the RFC variant marker. The other 30 digits carry random data.
The math behind “practically unique”
With 122 random bits there are 2^122 possible values, about 5.3 × 10^36. Collisions follow the birthday problem: you would need roughly 1.18 × 2^61 ≈ 2.7 × 10^18 UUIDs — about 2.7 quintillion — before the odds of even one duplicate reach 50%. Generating a million UUIDs every second, that stockpile would take about 86,000 years.
Another way to see it: if all 8 billion people on Earth each generated one million UUIDs (8 × 10^15 in total), the chance of a single collision — about n² divided by 2^123 — would be roughly 6 × 10^-6, or 0.0006%: about 1 in 166,000. For real applications the risk is negligible.
UUID versions at a glance
| Version | Built from | Time-sortable | Typical use |
|---|---|---|---|
| v1 | Timestamp + MAC address | Partially | Legacy systems |
| v4 | 122 random bits | No | General-purpose IDs |
| v5 | SHA-1 hash of a name | No | Deterministic, repeatable IDs |
| v7 | Unix timestamp + random bits | Yes | Database primary keys |
Frequently asked questions
UUID v4 vs v7 — which should I use?
v7 embeds the creation time in its leading bits, so v7 UUIDs sort chronologically. That makes them friendlier to B-tree indexes: new rows land at the end instead of scattering, which helps insert performance. Pick v7 for database primary keys; stick with v4 when ordering is irrelevant or you’d rather not leak creation timestamps.
Is a v4 UUID really unique?
Not by mathematical guarantee — uniqueness is probabilistic. But collision odds sit far below everyday failure modes, so the industry treats v4 UUIDs as unique. If you ever meet a “duplicate UUID”, the cause is almost certainly a cloning or copy-paste bug, not random chance.
Are UUID and GUID different things?
No — GUID (globally unique identifier) is simply Microsoft’s name for the same 128-bit standard, common in .NET, SQL Server and the Windows registry. You may see GUIDs in uppercase or wrapped in curly braces, but the value is interchangeable with a UUID.
Can someone guess a UUID? Can I use one as a secret?
UUIDs from crypto.randomUUID() come from a cryptographically secure generator, so they are not predictable in practice. Even so, treat them as identifiers, not secrets: the UUID spec does not require unpredictability from every implementation, and IDs leak into logs, URLs and analytics. For session tokens or API keys, use a purpose-built token generator instead.