Somewhere in your phone, your bank and every app you used today, records carry IDs like 3f8a2c1e-9b4d-4e6a-8f2b-7c5d9e1a3b6f, generated by machines that never asked anyone whether the ID was taken. UUIDs solve a deceptively hard problem, handing out identifiers with no central registry and no coordination, and they solve it with nothing but size: enough random bits that collisions stop being a realistic event in this universe. This guide explains the format, the math that makes the promise good, and the practical choices, with our free GUID generator producing as many as you need.
In this guide
The problem: unique without asking anyone
Sequential IDs, 1, 2, 3, are perfect inside one database and break the moment two systems generate independently: both issue a 47, and merging them corrupts history. Coordinating through a central counter fixes uniqueness and creates a bottleneck plus a single point of failure. The UUID bet goes the other way: make the ID space so vast, 128 bits, about 3.4 × 10³⁸ possibilities, that independently chosen random values simply do not meet. Two phones, offline, can each mint IDs for years and sync without conflict, not because anything prevented a collision but because probability did, at odds covered two sections down. GUID is the same thing under its Microsoft name; the dash-formatted hex is identical.
Anatomy: what the dashes and the 4 mean
The canonical form groups 32 hex characters as 8-4-4-4-12: the dashes are pure formatting, ignored by parsers and kept for human eyes. Two characters inside are reserved signals: the first character of the third group is the version, a 4 declaring “this UUID is random”, and the first character of the fourth group encodes the variant, landing on 8, 9, a or b in standard UUIDs. That bookkeeping spends 6 of the 128 bits, leaving a version-4 UUID with 122 bits of pure randomness, drawn from the cryptographically secure source covered in the randomness guide, the same well the random bytes generator taps. Spot a v4 at a glance: position one of group three reads 4, and the rest is noise by design.
The collision math, honestly
“Could two random UUIDs collide?” Yes, with probability so small the honest move is computing it rather than hand-waving. The birthday effect governs: collisions among n random IDs become likely when n approaches the square root of the space, and for 122 bits that threshold sits near 2.7 quintillion UUIDs. At a deliberately absurd rate, one billion UUIDs every second, reaching a coin-flip chance of a single collision anywhere takes about 86 years. Scaled to human reality: a system that generates a billion v4 UUIDs in total carries a collision probability around 10⁻¹⁹, billions of times less likely than the database holding them being corrupted by a cosmic-ray bit flip. The risk is never zero; it is engineered to be smaller than every other risk the system already accepts.
Versions: random, time-ordered, name-based
Version 4, fully random, is the default and what the generator produces. Version 7, the modern time-ordered variant, leads with a millisecond timestamp and fills the rest with randomness, so IDs sort by creation time, a property databases love, since fully random keys scatter inserts across an index while v7 keys append neatly. Versions 1 and 6 are the older time-based family, historically notable for embedding the machine’s network address, a privacy lesson the newer versions learned from. Versions 3 and 5 are deterministic, hashing a name into a UUID so the same input always yields the same ID, useful when “generate” really means “agree without talking”. The selection rule: v4 unless you need sortability (v7) or determinism (v5).
Practical choices and honest trade-offs
UUIDs cost what they give: 36 characters against a sequential ID’s handful of digits, unreadable over the phone, unguessable in both the good sense (enumeration attacks on /user/47 die instantly) and the bad (no human ever remembers one). Three working habits cover most teams. Store them in a native UUID column type where the database offers one, not as text, for size and speed. Choose v7 for primary keys in write-heavy tables, v4 everywhere else. And resist the temptation to parse meaning out of them: an ID that encodes nothing can never leak anything or need migrating when the encoded fact changes, which is precisely the design. The neighboring identifier topics, hashes and tokens, live in the security basics guide.
Frequently asked questions
Are UUIDs secure enough to use as secret tokens?
A v4 from a cryptographic source is unguessable in practice, but convention separates identifiers from secrets: IDs end up in logs, URLs and analytics where secrets must never live. Use UUIDs to name things, dedicated random tokens to protect things, and the distinction will never bite.
Why did I see the same UUID twice?
Almost certainly not a collision: the realistic causes are code reusing a variable, a copy-paste, a cache, or a weak generator seeded identically in two places. The math is so lopsided that “we found a v4 collision” is, operationally, always a bug report about the generator, not the probability.
Do dashes and letter case matter?
No: UUIDs compare case-insensitively and the dashes are display formatting, with lowercase-with-dashes as the canonical convention. Normalize before string comparison, or better, compare in the database’s native UUID type where formatting cannot interfere.
Is GUID different from UUID?
Same 128-bit object, two vocabularies: GUID is the Microsoft ecosystem’s historical name, UUID the standards name. Documentation mixing the two is describing one thing, and every generator on this site emits the standard form both worlds read.