What is a UUID in simple terms?
A UUID is a 128-bit identifier, written as 32 hex digits in five hyphenated groups. Any machine can create one on its own, with no central registry, because version 4 fills 122 of those bits with random data. The pool is so large that two UUIDs realistically never collide. Distributed systems and offline apps use them as record ids.
You have seen them everywhere: a string like f47ac10b-58cc-4372-a567-0e02b2c3d479 sitting in a URL, a database row, a config file, or a log line. That is a UUID, short for Universally Unique Identifier. The whole point of it is in the name. It is a value you can generate on your laptop, on a server in another country, or inside an app on a plane with no signal, and still be confident that nobody else will ever produce the same one.
That sounds like a bold promise, so it helps to understand how the format earns it. Once you see the structure, the magic turns into plain arithmetic, and you will know exactly when a UUID is the right tool and when a simpler number does the job better.
What does a UUID look like?
A UUID is a 128-bit number. On its own that is just a very large integer, so it is almost always written as 32 hexadecimal digits split into five groups by hyphens, in the pattern 8-4-4-4-12. The hyphens are purely for human eyes. They carry no information and you can strip them without changing the value.
Hexadecimal means each digit is one of sixteen symbols, 0 through 9 and a through f, so each digit packs four bits. Thirty-two of those digits give you the full 128 bits. If you find that notation interesting, it is the same base-16 idea that shows up in colour codes and memory addresses, and it sits next to other developer staples like Base64 encoding for turning binary into safe text.
How can it be unique without a central list?
This is the part that sounds impossible at first. No global registry checks whether your UUID has already been used. Uniqueness comes from sheer scale instead. The most common kind, version 4, fills 122 of its 128 bits with random data (six bits are reserved to mark the version and variant). That gives you about 5.3 undecillion possible values, a number with 36 zeros.
With a pool that vast, the chance of two random draws matching is so close to zero that engineers treat it as zero. To put it in perspective, you could generate a billion UUIDs every second for around 85 years before the odds of a single collision even reached fifty-fifty. That is why no coordination is needed. The maths does the coordinating.
Which UUID version should you use?
The UUID standard defines several versions. They all share the same 128-bit shape, but they fill the bits differently. A digit near the middle of the string tells you which version you are looking at. These are the ones you will actually meet.
Version 4: random
The workhorse. Almost entirely random, easy to generate, and what most languages and libraries hand you by default. If someone says “a UUID” without qualifying it, they usually mean a v4. Reach for it when you just need a unique id and do not care about ordering.
Version 1: time and machine based
Older, and built from a timestamp plus the network card’s MAC address. It is sortable by creation time, which is handy, but it can leak the time and the machine that made it. That privacy quirk is why many teams moved away from it.
Version 7: time-ordered random
The newer favourite. It puts a millisecond timestamp at the front and fills the rest with random bits, so you get the uniqueness of v4 plus a natural sort order. That ordering makes database indexes much happier, which is the main reason v7 has taken off for primary keys.
When to use one, and when not to
UUIDs solve a specific problem: creating unique identifiers in more than one place at once, without those places talking to each other. That makes them a natural fit for distributed systems, offline-first apps, and anywhere a record needs an id before it ever reaches a central database.
- Good fit: primary keys across many services, ids generated on a phone that syncs later, public-facing identifiers where you do not want to expose how many records you have (an auto-incrementing 1, 2, 3 quietly leaks your size).
- Poor fit: a small single-database app where a plain auto-incrementing integer is simpler, smaller, and faster to index. Do not add complexity you will not use.
- Wrong tool: anything that needs to be secret or unguessable for security. A UUID is unique, not a credential.
How do you generate a UUID?
You rarely need to write the logic by hand. Every mainstream environment can produce a UUID in a line or two. In the browser or Node, crypto.randomUUID() returns a v4. Python has uuid.uuid4(). PostgreSQL offers gen_random_uuid(). On a Mac or Linux box you can type uuidgen straight into the shell, which is one of those small wins of being comfortable working in the terminal. On Windows PowerShell the equivalent is [guid]::NewGuid(), since a GUID is just Microsoft’s name for the same thing. And when you want one or two without opening a shell at all, our free UUID generator creates valid v4 identifiers in your browser, one at a time or in bulk, with nothing sent to a server.
Whichever route you take, the output is the same familiar 36-character string. Generate it, copy it, paste it where it belongs, and trust that it will not clash with anyone else’s. That quiet reliability, with no central list and no coordination, is the whole reason UUIDs are everywhere once you start looking.
Sources
- RFC 9562: Universally Unique IDentifiers (UUIDs), RFC Editor (2024)
- UUID Functions, PostgreSQL Documentation
- uuid: UUID objects according to RFC 9562, Python Documentation
- Crypto: randomUUID() method, MDN Web Docs