UUIDs Explained: Versions and Use Cases
A plain look at universally unique identifiers and the versions you'll actually use.
A universally unique identifier, or UUID, is a 128-bit value used to label information in computer systems. The clever part is that different systems can each generate their own UUIDs, independently, with almost no chance of two of them colliding. Here's how they're put together and which versions you'll come across most often. There's a UUID generator on this site if you'd like to make a few.
Structure
You'll usually see a UUID written as 32 hexadecimal digits, split into five groups separated by hyphens, in the pattern 8-4-4-4-12. Something like 123e4567-e89b-12d3-a456-426614174000. A couple of positions in that string aren't random at all: they encode the UUID's version, which tells you how it was generated, and its variant, which describes the layout of the bits.
Version 4
Version 4 UUIDs are built mostly from random numbers. Out of the 128 bits, a handful are set aside to mark the version and variant, and everything else is random. This is the one you'll see everywhere, mostly because it asks nothing of you: no coordination between systems, no external lookups, just generate one and go. For most cases where you simply need a unique identifier, it does the job.
Version 7
Version 7, defined in a 2024 specification, mixes a timestamp with random data. The first chunk of the value is the time of generation in milliseconds, and random bits fill out the rest. Because that timestamp sits at the front, version 7 UUIDs created one after another tend to sort in roughly the order they were made. That turns out to be handy when you're using UUIDs as database keys, since it can make certain index operations more efficient than they'd be with fully random values.
Version 1
Version 1 was one of the original approaches. It combines a timestamp with a value derived from the hardware address of the generating machine's network interface. The catch is right there in the description: because it can fold in a hardware address, it may leak a little information about the machine that produced it, which matters in situations where that detail is sensitive. When you want time-based ordering without that worry, version 7 is usually the better pick.
Common use cases
UUIDs show up most often as identifiers for database records, especially when several systems are creating records and each needs to assign an ID without checking in with a central authority. They're also used to tag transactions, sessions, files, and plenty of other things. One quietly useful property: a system can generate a UUID locally, before it ever talks to a server, and trust that it's unique.
Considerations
A couple of things worth keeping in mind. When you store UUIDs in a database, a native UUID type, if your database has one, is generally more space-efficient than storing them as text. And if an identifier's unpredictability matters for security, make sure it's generated from a cryptographically secure source of randomness rather than an ordinary one. Beyond that, the version you reach for mostly comes down to whether you need time-based ordering and what the application actually requires.
Summary
So a UUID is a 128-bit identifier built to be unique across systems without any coordination. Version 4 is random, version 7 pairs a timestamp with random data and gives you time-based ordering, and version 1 uses a timestamp together with a hardware address. Which one fits depends on what your application needs.