If you've ever set up a database, worked with an API, or glanced at a URL that looked like 3f2504e0-4f89-11d3-9a0c-0305e82c3301, you've already encountered a UUID. They're everywhere in software, yet most people who use them have never stopped to ask what they actually are or how they work.
What is a UUID?
UUID stands for Universally Unique Identifier. It's a 128-bit number used to identify information in computer systems. The standard way to write one is as 32 hexadecimal digits split into five groups with hyphens:
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
For example: 550e8400-e29b-41d4-a716-446655440000
The "universally unique" part is the key idea. A UUID is designed so that, in practice, no two are ever the same, even if they're generated on different machines, in different countries, at the same moment. You don't need a central server to hand out IDs. You can generate one on your laptop and be confident it won't collide with one generated simultaneously in Tokyo.
Why use UUIDs?
The alternative to UUIDs is sequential IDs like 1, 2, 3. Those are simple, but they have problems:
- Predictability. If a record has ID 42, a user can easily guess that ID 43 exists. This leaks information and creates security risks (a type of vulnerability called IDOR — Insecure Direct Object Reference).
- Coordination required. When you have multiple databases or distributed systems, everyone needs to agree on who gets the next number. That requires centralized coordination, which introduces a bottleneck.
- Merge conflicts. If you sync two local databases, sequential IDs will collide.
UUIDs solve all three problems. They're long enough to be unguessable, generated independently without coordination, and statistically guaranteed not to collide.
UUID versions: which one should you use?
The UUID standard defines several versions, each generated differently. You'll encounter a few of them regularly.
UUID v1 — timestamp + MAC address
Version 1 encodes the current timestamp and the MAC address of the machine generating it. This means two v1 UUIDs generated on the same machine will be close in value (because the timestamp is similar), and they contain information about when and where they were created.
When to use it: Rarely in new projects, because the MAC address component leaks network information and the timestamp ordering makes UUIDs partially predictable.
UUID v4 — random
Version 4 is the most common today. It's generated from random (or pseudo-random) bytes, making it statistically unpredictable. The only non-random bits are the version indicator itself.
When to use it: Almost always. If you just need a unique, opaque ID for a database row, a session token, a file name, or any other purpose, v4 is the right choice. It's what most developers mean when they say "UUID."
UUID v5 — name-based (SHA-1)
Version 5 generates a UUID from a namespace and a name using SHA-1 hashing. The same namespace + name always produces the same UUID, making it deterministic. Version 3 works the same way but uses MD5 instead of SHA-1.
When to use it: When you need a stable, reproducible ID for a known piece of data. For example, if you want to generate a consistent UUID for a URL or a category name so the same input always maps to the same ID.
UUID vs GUID
You may have seen the term GUID (Globally Unique Identifier), particularly in Microsoft documentation and .NET code. A GUID is functionally the same thing as a UUID. Microsoft coined the term GUID, but both refer to the same 128-bit identifier format. They're interchangeable.
How likely is a UUID collision?
For UUID v4, the probability of generating a duplicate when you create a billion UUIDs is roughly one in a billion billion — that's approximately 1 in 10^18. In practice, collision is not something you need to worry about. The universe will end before you generate enough UUIDs to make a collision likely.
How to generate a UUID
You can generate UUIDs in any language:
- JavaScript / Node.js:
crypto.randomUUID()(built in, no library needed in modern environments) or theuuidnpm package - Python:
import uuid; uuid.uuid4() - PostgreSQL:
gen_random_uuid()(built in since Postgres 13) - MySQL:
UUID() - Go:
github.com/google/uuid
Or just use a browser-based tool when you need one quickly without writing any code.
Generate a UUID in your browser
The easiest way to get a UUID right now is to use Toolmingo's UUID Generator. It generates UUID v4 values entirely in your browser, no server involved. You can generate one or a batch, copy them, and use them immediately.
Nothing is sent to a server, nothing is logged. The IDs exist only in your browser until you copy them.
When NOT to use UUIDs
UUIDs are great identifiers, but they're not the right tool for everything:
- User-facing IDs in URLs. A UUID in a URL is ugly and hard to type. Use a short, readable slug or a shorter random ID (like a 10-character Base58 string) if humans need to interact with it.
- When you need chronological sorting. UUIDs v4 have no ordering. If you need IDs that sort by creation time, look at ULIDs or UUID v7, which are time-sortable.
- Tiny tables where collision is impossible anyway. If you have five categories in a config table, a sequential integer is cleaner.
FAQ
Q: Can I use a UUID as a primary key in my database? Yes, and it's common. The tradeoff is that UUIDs are larger (16 bytes vs 4 for an integer) and random UUIDs cause index fragmentation in databases that store rows in key order (like MySQL's InnoDB). For most applications this doesn't matter. For very large, write-heavy tables, consider ULID or UUID v7 instead.
Q: Are UUIDs case-sensitive?
No. 550E8400-E29B-41D4-A716-446655440000 and 550e8400-e29b-41d4-a716-446655440000 are the same UUID. The convention is lowercase, but most systems accept either.
Q: Do I need to generate UUIDs server-side? Not necessarily. Generating them client-side is fine for many use cases — a UUID v4 generated in the browser is just as unique as one generated on a server. The key question is whether you trust the client to generate a valid ID, which is usually fine for non-security-critical identifiers.