128 bits.
No central counter.
No collisions.

02 · Reading one

🔍 The 8-4-4-4-12 format

A UUID is 16 bytes. Its standard text form is 32 hexadecimal digits in five hyphen-separated groups of 8, 4, 4, 4 and 12 — 36 characters in total. Two positions tell you what kind of UUID you're looking at:

🪪 UUID vs GUID

They're the same thing. GUID (Globally Unique Identifier) is Microsoft's name, used in Windows, COM, .NET and SQL Server. The differences are cosmetic:

• Braces. Microsoft tools often show {3F0F8C5A-7C22-4B1F-9F07-2F7F9A8C2041}. The braces aren't part of the value.
• Case. The RFC says to output lowercase and accept either case on input. Compare case-insensitively.
• Byte order. .NET's Guid.ToByteArray() stores the first three groups little-endian, so its raw bytes differ from the RFC's order even though the string is identical. This only bites when you exchange binary UUIDs between platforms.

03 · Which kind

🧬 UUID versions compared

The version decides where the 128 bits come from. In practice you'll choose between v4, v7 and, occasionally, v5.

A v5 UUID for the DNS name quickdevelopertools.com is always 6a6e3815-b43b-593b-ab56-af1731b632b9, on every machine, forever — handy when two systems need to derive the same ID from the same natural key without talking to each other.

04 · The honest maths

🎲 Will a v4 UUID ever collide?

A v4 UUID has 128 bits, but 6 are fixed (4 for the version, 2 for the variant), leaving 122 random bits — about 5.3 × 10³⁶ possible values.

The right way to think about collisions is the birthday problem: the question isn't whether a new ID matches one specific ID, it's whether any two IDs in your whole set match. That probability grows with the square of how many you've made. Even so:

For any realistic system — even billions of rows — the chance of a v4 collision is so small it's dwarfed by hardware faults and ordinary bugs. You can use v4 IDs without a uniqueness check in the application, though keeping a unique constraint in the database costs little and protects you from the failure mode that does happen:

05 · Primary keys

🗄️ v7 for database keys & index locality

Random v4 keys have a performance cost in B-tree indexes — the structure behind most primary keys. Each new row lands at a random spot in the index, so inserts touch pages all over it: more page splits, a larger working set that has to stay in memory, and a fragmented index over time.

v7 fixes that by putting the timestamp first. New IDs are always slightly larger than recent ones, so inserts cluster at the end of the index, much like an auto-increment integer — while keeping the "generate anywhere" benefit.

019cebae-61c0-7a3c-9e41-5b8d0f2a6c17
└─ timestamp ─┘ │     │
   2026-03-14    │     └ variant
   09:30:00Z     └ version 7         the rest: random

💡 Store UUIDs in a native uuid / uniqueidentifier column or as 16 bytes of binary — not as a 36-character string, which more than doubles the size of every index that includes it.

06 · In your code

🛠️ Generating UUIDs

crypto.randomUUID();   // v4 — browsers (secure contexts, i.e. HTTPS) and Node.js

Guid id   = Guid.NewGuid();           // v4
Guid v7   = Guid.CreateVersion7();    // v7 — .NET 9 and later
string s  = id.ToString();            // "3f0f8c5a-7c22-4b1f-9f07-2f7f9a8c2041"
string n  = id.ToString("N");         // no hyphens
bool ok   = Guid.TryParse(input, out var parsed);

import uuid

uuid.uuid4()                                          # v4
uuid.uuid5(uuid.NAMESPACE_DNS, "quickdevelopertools.com")  # v5
uuid.uuid7()                                          # v7 — Python 3.14+

-- PostgreSQL
SELECT gen_random_uuid();   -- v4 (built in since PostgreSQL 13)
SELECT uuidv7();            -- v7 (PostgreSQL 18+)

-- SQL Server
SELECT NEWID();             -- random GUID

# Linux / macOS
uuidgen