UUID Generator

What a UUID Is, and Why Distributed Systems Depend on It

A UUID (Universally Unique Identifier), also called a GUID, is a 128-bit value written as a 36-character string with hyphens. The problem it solves is concrete: in a system made of many machines, many services, and often many data centers, how do you give every record, every request, and every session a name that will never collide with another, without a central authority handing out numbers? That is the fundamental difference from an auto-increment primary key, which needs one coordinator to remember "what number comes next." A UUID lets any machine mint non-colliding identifiers on its own. This is precisely why UUIDs became standard in distributed databases, message queues, microservice tracing, session management, and data migration.

Most of the "random codes," "order-number suffixes," and "trace ids" you meet in daily development are UUIDs under the hood. They carry no business meaning and only promise uniqueness, which makes them remarkably convenient when stitching data together across systems: you never worry that two systems both starting from 1 will clash.

The Five Official UUID Versions: How They Are Made and Where They Fit

RFC 4122 defines several UUID versions, differing in how the 128 bits are computed. The table below puts all five side by side and marks how commonly each is used in real projects:

How to use this: for almost any web project or ordinary business system, v4 is the right default: it is the simplest, the most universal, and it needs no input at all. Only when you "want the same name to always produce the same ID" (such as deriving a stable ID from a URL) do you need the name-based, deterministic v3 or v5. v1 is rarely used in new projects because it writes the MAC address into the ID.

The 8-4-4-4-12 Format and What Each Part Means

A standard UUID is 36 characters across five groups whose lengths are 8, 4, 4, 4, and 12, separated by hyphens, which is why it is called the 8-4-4-4-12 format. Stripping the hyphens leaves 32 hexadecimal characters, i.e. 128 bits. Two positions inside those 128 bits are reserved to encode identity:

First, the first hexadecimal character of the third group (the high 4 bits of its first byte) always marks the version. A v4 UUID therefore always begins its third group with the digit 4; v1 begins with 1; v5 begins with 5. Second, the first hexadecimal character of the fourth group (the high 2 bits of its first byte) always marks the variant. Under RFC 4122 it must be the binary pattern 10, which in hexadecimal means that digit can only be 8, 9, A, or B. Whenever the fourth group starts with one of those four characters, you can tell the value is an RFC 4122 UUID.

Worked Example: Taking Apart a UUID String

Example 1 (following the brief): take the string 123e4567-e89b-12d3-a456-426614174000. Split it by 8-4-4-4-12: group 1 is 123e4567 (8), group 2 is e89b (4), group 3 is 12d3 (4), group 4 is a456 (4), group 5 is 426614174000 (12). Look at the first byte of group 4, a: hexadecimal a is binary 1010, whose top two bits are 10, matching the RFC 4122 variant. Now look at the first byte of group 3, 1, which marks it as version 1. To turn it into a proper v4, change only the first byte of group 3 to 4, yielding 123e4567-e89b-42d3-a456-426614174000, where group 3 starts with 4 and group 4 still starts with a, a format-correct v4. Every result this tool produces keeps group 3 starting with 4 and group 4 starting with 8, 9, A, or B, so you can pick any output and verify it yourself using the method above.

Frequently Asked Questions Specific to UUIDs

Is UUID v4 truly unique? What is the collision probability?

v4 has 122 random bits, a space of 2 to the 122nd power, roughly 5.3 times 10 to the 36th. To grasp that scale: even if you generated one billion UUIDs every second for 100 years straight, the chance of a single collision would still be far lower than being struck by a meteor. So it is not "mathematically impossible to repeat," but "safe to treat as unique across any practical timeframe." The real risk is not random collision but your own code writing the same UUID twice, which has nothing to do with the algorithm.

UUID v1 leaks the MAC address. What is the privacy risk?

v1 encodes the generating machine's MAC address directly into the fifth group of the UUID. That means anyone holding a v1 UUID can, in theory, reverse-engineer which network card produced it, tying the value to a specific device or even a physical location. Inside trusted internal networks of the past this was acceptable, but in today's public, multi-tenant cloud environments, writing a hardware address into an externally visible ID is clearly undesirable. This is why new projects overwhelmingly switch to v4, which carries no hardware information, and why v1 survives mainly in internal systems that need time ordering and trust their network boundary.

How do I choose between UUID v4 and v5?

The core difference is random versus deterministic. v4 is different every time and fits cases where you only care about uniqueness and not about any relationship to a name, such as session IDs, tokens, and trace numbers. v5 (and v3) do the opposite: given the same namespace and the same name, they always yield the same UUID, which fits "I want to map a stable thing, like a URL or a username, to a fixed ID." A simple rule: when you need unique but unrelated values, use v4; when you need "same name always gives same value," use v5.

What is the real difference between a UUID and an auto-increment ID?

An auto-increment ID (1, 2, 3, ...) is issued by the database itself: compact, ordered, and index-friendly, but with two hard flaws. First, it writes your business scale directly into the ID, so a competitor holding your order number can estimate your sales volume. Second, when data must be merged or migrated across machines or databases, two databases both starting from 1 will inevitably clash. A UUID trades a longer string for two benefits: identifiers generated independently on any machine never collide, and they reveal no business scale. The cost is larger storage (36 characters versus an integer) and unordered insertion that can make indexes slightly slower. In practice: for a single machine with storage and order sensitivity, use auto-increment; for distributed writes, cross-system migration, or hiding your scale, use a UUID.