UUID: What This Identifier Is and Why It Almost Never Repeats

550e8400-e29b-41d4-a716-446655440000 — if you've ever opened a service's settings, a database, or a log, you've definitely seen strings like this. It's a UUID (Universally Unique Identifier) — an identifier that is "guaranteed" unique: you can generate one on a phone or on a server in the other hemisphere and not worry that anyone will ever create the same one. What follows: how those 128 bits are put together, how version 4 differs from 1 and 5, when a UUID beats a plain counter, and why a database is better off storing it as bytes rather than a string.

How it's structured

A canonical UUID is 32 hexadecimal characters broken by hyphens into groups of 8-4-4-4-12. That's 128 bits of information in total, but not all of them are random: a few bits encode the standard's version and variant. In the most common format, UUID v4, 122 bits are random — about 5.3×10³⁶ possible values. For a sense of scale: if every person on Earth generated a billion UUIDs per second, an accidental collision would still be practically impossible.

550e8400-e29b-41d4-a716-446655440000
version: first character of the third group → "4" → this is UUID v4
variant: leading bits of the fourth group → "a" = 1010 → the RFC 4122 variant
the remaining 122 bits are random (in version 4)
the hyphens carry no data, they just split the string into readable groups

Hyphens are part of the notation, not part of the data: take them away and you still have the same 128 bits, just an unreadable string. Their value is practical — the data itself is 16 bytes, i.e. 32 hexadecimal digits, and people happily mix up an 8 and a B or drop a character while copying. With the hyphens such a mistake is obvious right away: not 32 characters in a row, but 8-4-4-4-12.

Is GUID the same thing?

The word GUID comes from Microsoft: Global Unique Identifier. The format is exactly the same — 128 bits, groups of 8-4-4-4-12 — only the terminology differs. You will see "GUID" in the Windows and .NET documentation, in the registry and in COM object identifiers, and "UUID" in RFC 4122 and in databases such as Postgres. It is the same value under two names. There is one practical difference in how they are written: Windows spells GUIDs in uppercase inside braces — {550E8400-E29B-41D4-A716-446655440000} — while databases and APIs use lowercase without braces. Compare values case-insensitively.

Versions: how they differ

• v1 — timestamp and machine ID: deterministic, but it reveals when and where it was created;
• v4 — pure randomness: the de facto standard for public identifiers;
• v5 — a hash of a name: the same input always yields the same UUID, handy for stable identifiers derived from URLs or names;
• v3 — the same idea on an MD5 hash: it shows up in older systems and in values generated years ago;
• v7 — a newer time-based variant (RFC 9562): such identifiers grow monotonically, so their order of creation is visible.

The position where the version "sits" is the first character of the third group: in the example above it's 4 (v4), and the "a" in the fourth group marks the standard's variant. Now you can identify a version at a glance. Take any UUID from your project and look at the first character of the third group: 1, 3, 4, 5 or 7 — the version is readable without opening the docs.

When a UUID beats a plain counter

A counter — 1, 2, 3 — works fine as long as one server creates the records and also hands out the numbers. The moment there are two sources (a web app plus a mobile app that works offline), you need a coordinator: someone has to issue the next number, otherwise you get a collision. A UUID removes that problem — every participant generates its own identifier and no conflicts arise. The price is length: 36 characters instead of a short number, and random values sort poorly in a database index. That's why UUIDs are often stored as 16 bytes rather than as text: Postgres has a dedicated uuid type and MySQL has a binary UUID, and the saving in space is noticeable.

How to check that you are looking at a UUID

The check takes a second. There should be 36 characters: 32 hexadecimal ones (digits 0–9 and letters a–f) and 4 hyphens at positions 9, 14, 19 and 24. The first character of the third group tells you the version, and the first character of the fourth group tells you the variant: values 8, 9, a or b mean the string follows RFC 4122. If the length isn't 36 or the string contains characters above f, it isn't a UUID but something else: a database key, a hash, or plain text.

Why it matters in practice

The main advantage over "just a counter" is that identifiers can be created without a central coordinator: different services, an offline app, a script on a laptop — each generates its own UUID, and no conflicts arise. That's why UUIDs live in document URLs, in transaction IDs, in uploaded file names, and in logs — anywhere you need to reliably refer to "this exact entity." Worth adding that a UUID means nothing: it doesn't reveal the size of your database, doesn't hint at record order and doesn't carry a date, so there's no reason to be shy about showing it in a public API.

You can generate a batch of UUIDs in the UUID generator: it produces v4 via the browser's cryptographic generator, several at a time. If you need test numbers in other numeral systems, the base converter is right next door. And to hash a name — the building block of version 5 — the hash generator will show the result in hexadecimal right away.

Frequently asked questions

Can you tell what device or file a UUID belongs to?

No. A UUID is a random label with no content: it reveals neither the type of object, nor the creation time, nor the owner. Its only purpose is to tell objects apart beyond any doubt. Version 1 is the exception — it really does carry a timestamp and a node identifier, so the time of creation can be estimated from it. But in v4, by far the most common one, there is no information at all: those 122 random bits mean nothing.

Can two UUIDs collide?

UUID v4 carries 122 random bits — 5.3 × 10³⁶ possible values. The chance of two generated UUIDs matching is so small it is ignored: you would have to generate billions of identifiers per second for centuries to see a duplicate. It is fairer to count from a different angle: by the birthday paradox the risk becomes noticeable at around 2⁶¹ ≈ 2.3 × 10¹⁸ identifiers. If you generate a million UUIDs per second, it would take roughly 70,000 years to get there.

Why does a UUID contain letters and hyphens?

UUIDs are written in hexadecimal, which uses the letters a–f alongside digits, and hyphens split it into readable groups of 8-4-4-4-12 characters. The string is just a representation — the identifier itself is 128 bits. The practical reason for the hyphens is simple: without them a 32-character string is awkward to read, and one character gets lost in copying, while with them the mistake is visible at once — not 32 characters in a row, but 8-4-4-4-12.

What's the difference between a UUID and a GUID?

Practically none: it's the same 128-bit format under two names. GUID (Global Unique Identifier) is Microsoft's term, used in the Windows and .NET documentation, in the registry and in COM object identifiers. UUID (Universally Unique Identifier) comes from the RFC 4122 standard and is what databases (Postgres has a uuid type) and APIs use. The difference is in how they are written: Windows spells GUIDs in uppercase inside braces — {550E8400-E29B-41D4-A716-446655440000} — while UUIDs go lowercase and without braces. Compare the values case-insensitively.

Is UUID v4 secure? Could someone guess it?

It cannot be guessed: in version 4, 122 bits are random, i.e. 5.3 × 10³⁶ combinations, and brute force is out of the question. But in another sense a UUID gives no protection: it's a public identifier that sits in URLs, in logs and in API responses, so on its own it guards nothing. A token that genuinely authorizes someone is made separately — with a signature and a short lifetime, as we covered in the article on JWT.

Should a UUID be stored in the database as a string or as a number?

It depends on the job. A uuid column in Postgres stores the value compactly — 16 bytes — and indexes on it behave properly; MySQL offers a binary UUID for the same reason, also 16 bytes instead of 36 characters. Storing it as a 36-character string is simpler, but it's 2.25 times longer and the index on such a column is heavier. One more detail: if the UUID ends up in a file or a URL, the canonical text form will be needed anyway — converting between the binary and text views takes milliseconds.