If you have ever looked at a database, an API response, or an app's settings file, you have probably seen strings like 550e8400-e29b-41d4-a716-446655440000. That odd-looking jumble of letters, numbers, and dashes is a UUID, one of the most quietly important building blocks in modern software.
UUID stands for Universally Unique Identifier. It is a 128-bit label that can identify anything, a database row, a user session, a file, a device, without a central authority handing out numbers. This guide explains what a UUID actually is, the different versions you will run into, and when reaching for one is the right call.
A UUID is a 128-bit number, usually written as 32 hexadecimal characters grouped in a 8-4-4-4-12 pattern, separated by dashes:
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
For example:
550e8400-e29b-41d4-a716-446655440000
Those 128 bits give UUIDs an address space so enormous that collisions, two UUIDs accidentally being the same, are practically impossible. There are 2^128 possible UUIDs, about 340 undecillion. Even if you generated a billion UUIDs every second for a hundred years, the chance of a single collision would still be vanishingly small.
That is the whole point. Unlike a simple counter (1, 2, 3...), a UUID can be created anywhere, by anyone, at any time, with no coordination, and it will still be unique. Two servers on opposite sides of the planet can each generate IDs all day without talking to each other, and neither will step on the other's toes.
Not all UUIDs are made the same way. The version is encoded in the UUID itself: look at the first character of the third group. In the example above, 41d4 starts with a 4, so it is a version 4 UUID. The versions you are most likely to meet:
If you are not sure which to pick, version 4 is the safe default. If you need IDs that sort by creation time for database performance, look at version 7.
UUIDs shine in specific situations. Here are the cases where they are genuinely the right tool:
Distributed systems. When multiple servers, devices, or offline clients all create records that later merge into one database, a central counter becomes a bottleneck. UUIDs let every node generate IDs independently.
Database primary keys. Auto-increment integers are simple, but they reveal how many records you have (your user with ID 47 knows you only have 47 users), and they are painful to merge across databases. UUID primary keys avoid both problems.
Public-facing identifiers. URLs like /orders/9 invite curious users to try /orders/10 and see someone else's data. A UUID-based URL is not guessable, which is a meaningful layer of protection, though not a substitute for real authorization checks.
API and session tokens. When your API hands out identifiers for resources, UUIDs keep them unique across clients without the server tracking a counter per client.
File and asset naming. Uploaded files named with UUIDs never collide, even when two users upload different files called photo.jpg at the same moment.
UUIDs are not free. Knowing when to skip them is just as important:
When you need short, human-friendly codes. Nobody wants to read a 36-character ID over the phone. Order numbers, confirmation codes, and invite codes are better as short alphanumeric strings.
When storage and index size matter a lot. A UUID takes 16 bytes versus 4 or 8 for an integer. In a table with hundreds of millions of rows and many indexes, that difference adds up, and random UUIDs fragment indexes more than sequential IDs. If you need UUIDs at scale, consider version 7.
When the value must be secret. A version 4 UUID has 122 bits of randomness, making it unguessable in practice, but UUIDs are identifiers, not secrets. For passwords, API keys, and cryptographic tokens, generate proper random secrets with a dedicated password generator.
When you need to verify integrity. A UUID tells you nothing about whether data was tampered with. To fingerprint content or verify a file has not changed, compute a hash with an online MD5 generator or a stronger algorithm instead. Hashing and unique identification solve different problems.
The most common decision developers face is UUID versus a simple auto-incrementing integer. Here is how they compare:
The rule of thumb: integers for internal tables that never merge, UUIDs for anything distributed, public-facing, or merged across systems. Many projects use both, integers internally and UUIDs on the API boundary.
There is a privacy angle worth noting too. Just as a sequential user ID leaks business information, other identifiers can leak personal details. If you run a website, our guide on what domain privacy protection is explains how to keep your personal details out of public WHOIS records, a different kind of identifier hygiene that matters just as much.
Generating a UUID takes one click. Our free UUID generator creates version 4 UUIDs instantly in your browser, with no sign-up and nothing sent to a server. Click generate, copy the result, and paste it wherever you need a unique identifier.
If you need UUIDs in code rather than by hand, every major language has built-in support:
import uuid
# Random (version 4) UUID
print(uuid.uuid4())
# Time-ordered style identifier
print(uuid.uuid1())
// Modern browsers and Node.js
console.log(crypto.randomUUID());
One important note: always use a cryptographically secure random source when generating version 4 UUIDs, especially if the IDs will be public. The examples above both do. Never seed UUID generation with something predictable like the current time alone, or the "uniqueness" guarantee quietly evaporates.
A UUID is a 128-bit identifier you can generate anywhere, anytime, confident it will never collide with another. Version 4 is the default choice, version 7 is the modern answer for database keys, and version 5 covers the deterministic cases. Use them for distributed systems, public-facing IDs, and anything that needs to merge cleanly. Skip them for short human codes, tight storage budgets, and actual secrets.
They are a small piece of infrastructure that solves a big coordination problem, which is why they show up in practically every codebase you will ever touch.
Need a fresh identifier right now? Generate one instantly with our free UUID generator. No sign-up, no waiting, just a unique ID ready to paste into your database, API, or config file.
UUID stands for Universally Unique Identifier. It is a 128-bit label used to identify information in computer systems, typically written as 32 hexadecimal characters in a 8-4-4-4-12 pattern separated by dashes.
Version 4 UUIDs are generated from random numbers, so each one is independent and unpredictable. Version 7 UUIDs combine a timestamp with random bits, which means they sort naturally by creation time while remaining unique. Version 4 is the most common default; version 7 is better for database primary keys because time-ordered IDs index more efficiently.
In theory yes, in practice no. With 2^128 possible values, the chance of a collision is so small that you would need to generate billions of UUIDs per second for a century before it became a realistic concern. For all practical purposes, UUIDs are unique.
No. A version 4 UUID has 122 bits of randomness and is unguessable in practice, but UUIDs are identifiers, not secrets. They are not designed for authentication, and some versions leak timestamps or machine details. For passwords, API keys, and tokens, use a dedicated password or secret generator built for that purpose.
Use auto-increment integers for internal tables that will never merge with another database, since they are smaller and faster to index. Use UUIDs for distributed systems, public-facing identifiers, and anything that might one day merge across databases. Many projects use both: integers internally, UUIDs on the API boundary.
