A UUID is a 128-bit identifier, typically written as 32 hexadecimal characters grouped into five sections separated by hyphens, for example `550e8400-e29b-41d4-a716-446655440000`. The point of a UUID is to let completely independent systems, servers, or people generate identifiers without ever talking to each other or a central authority, and still end up with values that never collide in practice.
Why randomness alone is enough
The most common type, version 4, is generated almost entirely from random bits (122 of the 128 bits are random, with a handful reserved to mark the version and variant). With 122 random bits, the total number of possible UUIDs is roughly 5.3 undecillion, a number so large that even generating a billion UUIDs per second for a hundred years wouldn't bring the probability of a single collision anywhere close to 1%. This is the birthday-paradox math in action: collisions become likely only once you've generated a number of items on the order of the square root of the total space, and the square root of 5.3×10^36 is still astronomically large.
That's fundamentally different from something like an auto-incrementing database ID, which is only unique within one table on one database, two different systems can easily both produce "user #4102." A UUID generated independently on a laptop, a server, and a mobile app all end up compatible because none of them need to coordinate, which is exactly why UUIDs are the default choice for distributed systems, offline-first apps, and anywhere IDs need to be assigned before a record ever reaches a central database.
UUID versions aren't interchangeable
Version 4 (random) is the most common and what people usually mean by "a UUID," but other versions exist for different purposes: version 1 encodes a timestamp and the generating machine's network identifier, version 3 and version 5 are deterministic, generated by hashing a namespace and a name so the same input always produces the same UUID, useful when you need a stable ID derived from existing data rather than a random one. If you need a shorter, URL-friendly unique identifier instead, tools like the ULID Generator produce sortable alternatives that encode a timestamp directly into the value.
Where UUIDs actually get used
Database primary keys, API resource IDs, session tokens, and file names in distributed storage systems all commonly use UUIDs specifically because no coordination is needed to guarantee uniqueness. The tradeoff is that UUIDs are longer and less human-readable than sequential integers, and a random UUID as a database primary key can hurt index performance on some databases because inserts land at random positions in the index rather than appending at the end, which is one reason time-ordered alternatives like ULIDs exist for high-throughput systems.