UUID in one paragraph
UUID stands for Universally Unique Identifier. It is a 128-bit number, written as 32 hexadecimal digits split into five groups with hyphens. The whole point is in the name: you can generate one anywhere, on any machine, without asking anyone for permission, and be confident it will not clash with an ID generated somewhere else.
That is the problem UUIDs solve. If two servers both need to create records with unique IDs, a simple counter (1, 2, 3...) fails, because both servers would hand out the same numbers. A UUID sidesteps the problem by making collisions so unlikely they are not worth worrying about.
Anatomy of a UUID
A standard UUID looks like this: 550e8400-e29b-41d4-a716-446655440000. The five groups have 8, 4, 4, 4, and 12 characters. The characters are hexadecimal, meaning digits 0-9 plus letters a-f.
One digit is special: the first character of the third group tells you the version. In the example above it is a 4, so this is a version 4 UUID. The version tells you how the ID was built, which brings us to the versions that actually matter.
The versions you will meet
There are several UUID versions, but in practice you will run into two:
Version 1 is built from the current timestamp plus an identifier for the machine that created it. These IDs are roughly time-ordered, which some databases like, but they leak information: anyone reading the UUID can tell when it was created and on which machine. For that reason, v1 has fallen out of favor.
Version 4 is purely random (122 random bits, to be precise). No timestamp, no machine info, nothing to leak. This is the default choice today, and it is what most generators produce, including ours.
There are newer versions too. Version 7 combines a timestamp with randomness, giving you time-ordering without the privacy downsides of v1. If your database sorts by primary key, v7 is worth knowing about. But for most everyday uses, v4 is the right answer.
When should you actually use one?
Reach for a UUID when IDs are created in more than one place and still need to be unique without a central authority handing them out. The classic cases:
Database primary keys, especially when data is created on multiple servers or synced from mobile apps that work offline. Each device generates its own IDs, and they never collide when the data merges.
API request and transaction IDs. When a request passes through five microservices, giving it one UUID at the start makes it trivial to trace through every log.
File and upload identifiers. Naming uploaded files with UUIDs avoids filename clashes and does not expose how many files you have, unlike sequential numbers.
When should you not bother? If you have a single database with a single writer, a plain auto-incrementing number is simpler, shorter, and indexes better. UUIDs are a tool for a specific problem, not a default for everything.
Generate one in seconds
If you need a UUID right now, you do not need to install anything or write code. Our UUID generator creates version 4 UUIDs instantly in your browser. One click to generate, one click to copy, done. Nothing is sent to a server, so the IDs you generate stay private.
It sits alongside our other generator tools, like the password generator and random number generator, all free and all running locally in your browser.
Frequently asked questions
What does UUID stand for?
UUID stands for Universally Unique Identifier. It is a 128-bit number written as 32 hexadecimal digits in five groups, like 550e8400-e29b-41d4-a716-446655440000.
Are UUIDs really unique?
For practical purposes, yes. A version 4 UUID has 122 random bits, which means about 5.3 x 10^36 possible values. The chance of two randomly generated UUIDs colliding is so small you can safely ignore it.
What is the difference between UUID v1 and v4?
Version 1 UUIDs are built from the current timestamp plus a machine identifier, so they are time-ordered but can leak information about when and where they were created. Version 4 UUIDs are purely random, which makes them the safer default for most uses.
When should I use a UUID instead of a simple number?
Use a UUID when IDs are created in different places or systems and still need to be unique without checking a central counter. Database primary keys, API request IDs, and distributed systems are the classic cases.