A UUID — Universally Unique Identifier — is a 128-bit label that looks like 550e8400-e29b-41d4-a716-446655440000. Its entire purpose is to be unique without any central authority handing out numbers, and that quiet property makes it one of the most widely used building blocks in modern software. If you have used almost any app or website, UUIDs have been working behind the scenes on your behalf.
This guide explains why simple sequential numbers are not enough, why UUID collisions are effectively impossible, where UUIDs are used, and the important distinction between a UUID (an identifier) and a secret (which it is not).
Sequential IDs work perfectly in a single database on a single machine. The trouble starts the moment more than one system creates records independently. If two servers both assign "record 101" without coordinating, you get a collision, and merging their data becomes a mess.
UUIDs solve this by letting any machine, anywhere, generate an identifier it can safely assume no other machine will ever produce — no shared counter, no central server, no coordination required. That independence is exactly what distributed systems need.
In theory, two randomly generated UUIDs could match. In practice, the odds are so astronomically small that engineers treat them as impossible. There are roughly 3.4 × 10³⁸ possible version-4 UUIDs — a number with 38 digits.
To put that in perspective: if you generated a billion UUIDs every second for a hundred years, the probability of a single duplicate would still be vanishingly small. For all real-world purposes, a freshly generated UUID is unique, which is why systems rely on them without a second thought.
Once you know what to look for, UUIDs are everywhere in software:
Need one right now? The UUID Generator produces valid version-4 (random) UUIDs instantly, one at a time or in bulk.
If you need something secret, generate a proper credential with a password generator or a cryptographic token generator. UUIDs and secrets serve different purposes, and conflating them is a common security mistake in early software projects.
People sometimes confuse UUIDs with hashes because both are long strings, but they work in opposite ways. A UUID is a fresh random label with no relationship to any input — generate two for the same thing and they differ. A Hash Generator is a fixed fingerprint derived from specific input, so the same input always produces the same hash.
Use a UUID when you need to label something new and unique. Use a hash when you need to verify that some data has not changed, or to look something up by its content. The choice follows directly from whether the identifier should depend on the data or be independent of it.
There are several UUID versions, but two matter for most people. Version 4 is purely random and is the default choice for general-purpose unique IDs — it is what most generators produce. Version 7, newer, embeds a timestamp so the IDs sort roughly in creation order, which can improve database performance.
Unless you have a specific reason to sort by creation time, version 4 is the right default. It is simple, universally supported, and unique enough for essentially any application.
A UUID's 36-character string is not random-looking by accident; it has a defined structure. Written as eight-four-four-four-twelve hexadecimal digits separated by hyphens, certain positions carry meaning.
In the example 550e8400-e29b-41d4-a716-446655440000, the digit marked in the third group indicates the version — here a 4, meaning randomly generated. The first digit of the fourth group indicates the variant, a technical detail about the layout standard. The remaining digits are the actual unique value, which for version 4 is essentially random.
You almost never need to read these fields by hand, but knowing they exist explains why UUIDs from a proper generator all share a similar shape while remaining unique, and why a string that looks like a UUID but has the wrong structure — a missing hyphen, the wrong version digit — may be rejected by systems that validate the format. A good generator always produces correctly structured, valid UUIDs, which is safer than assembling one by hand.
UUIDs are the most widely used unique identifier, but they are not the only option, and knowing the alternatives clarifies when a UUID is the right tool and when something else fits better.
The right choice depends on your needs. If you have a single database and value compactness and ordering, an auto-incrementing integer is often fine. If you need identifiers generated independently across many systems without coordination, a UUID is the standard answer. If you want that independence and rough time-ordering — useful for database performance — a version-7 UUID or ULID gives you both. What all of these share is the goal of a reliable, unique label; they differ mainly in whether they need coordination, whether they sort by time, and how much they reveal. For general-purpose use where independence matters, the random version-4 UUID from a generator remains the simplest safe default.