If you have worked with databases, APIs, or distributed systems, you have seen strings like 550e8400-e29b-41d4-a716-446655440000. That is a UUID — a universally unique identifier — and it is one of the most common ways to label a piece of data without coordinating with a central authority. This guide explains what a UUID is, how the main versions differ, how unique they actually are, and which one to reach for.
What is a UUID?
A UUID (also called a GUID in the Microsoft world) is a 128-bit value, almost always written as 32 hexadecimal digits split into five groups separated by hyphens: 8-4-4-4-12 characters. The format is standardized in RFC 4122 (and its 2024 successor), so a UUID generated on one machine has the same shape as one generated anywhere else.
The whole point of a UUID is that you can generate one locally, on any device, at any time, and be confident it will not clash with a UUID generated by someone else. No database round-trip, no shared counter, no coordination required.
Why use a UUID instead of an auto-increment ID?
Traditional databases hand out sequential integer IDs: 1, 2, 3, and so on. That works well in a single database, but it has downsides. Sequential IDs require the database to assign them, so you cannot know an object's ID before you insert it. They leak information — an order numbered 1043 tells a competitor roughly how many orders you have. And they make merging data from multiple sources painful, because two systems will both have a row with ID 1.
UUIDs solve all three. You can generate the ID in your application before touching the database, they reveal nothing about volume, and records from different systems never collide. The cost is that they are larger and less human-friendly than a small integer.
UUID v4: random
Version 4 is by far the most common. It is generated almost entirely from random (ideally cryptographically secure) bits — 122 of the 128 bits are random, with a few reserved to mark the version and variant. Because it is pure randomness, a v4 UUID carries no embedded information about when or where it was created, which is exactly what you want when you simply need an opaque, unguessable identifier.
For most applications — API resource IDs, idempotency keys, session tokens, file names — v4 is the right default.
UUID v1: timestamp + node
Version 1 is built from the current timestamp plus a node identifier (historically the machine's MAC address) and a small counter. Because it embeds the time, a batch of v1 UUIDs is roughly ordered by creation, which can help database index locality.
The trade-off is privacy and predictability: a v1 UUID can leak the generating machine's identity and the moment of creation, and it is more guessable than v4. For that reason, v1 has fallen out of favor for anything user-facing.
UUID v7: the modern choice for database keys
The 2024 update to the UUID spec introduced version 7, which combines a Unix millisecond timestamp with random bits. This gives you the best of both worlds: the values are time-ordered (so they sort chronologically and keep database indexes compact) while still being effectively unique and non-sequential.
If you are choosing a UUID specifically to be a primary key in a modern database, v7 is increasingly the recommended option, because purely random v4 keys can hurt insert performance on large B-tree indexes. Versions 3 and 5 also exist for generating deterministic UUIDs from a namespace and a name, useful when you want the same input to always map to the same UUID.
How unique are UUIDs, really?
For v4, the odds of a collision are astronomically small. With 122 random bits, you would need to generate billions of UUIDs per second for many years before the probability of a single duplicate became meaningful. In practice, for any normal application, you can treat v4 UUIDs as unique and never think about collisions again.
The caveat is that this relies on a good source of randomness. A weak or broken random number generator can produce duplicates, which is why generating UUIDs with a trusted, cryptographically secure source matters.
How to generate a UUID
You can create UUIDs instantly with the free UUID generator on ToolboxHub. It produces RFC 4122 v4 UUIDs (and v1) right in your browser using the secure crypto API, with single or bulk generation and one-click copy. It is handy for seeding test data, creating idempotency keys, or grabbing a quick unique identifier while you code — and nothing is sent to a server.
The short version
A UUID is a 128-bit, RFC 4122 identifier you can generate anywhere without coordination. Use v4 (random) as your everyday default for opaque IDs. Reach for v7 when you need time-ordered keys that play nicely with database indexes. Avoid v1 for anything user-facing because it can leak time and machine info. And thanks to 122 bits of randomness, v4 collisions are something you can safely ignore.