UUID versions and when to use each
How v4 random UUIDs compare with v1, v5 and v7, what the version and variant digits mean, and which one fits your use case.
Reading the version and variant digits
A canonical UUID has the shape 8-4-4-4-12, thirty two hex digits split into five groups. Two positions are not random. The first digit of the third group is the version number, which is 4 for the random UUIDs this tool produces. The first digit of the fourth group is the variant, which for standard UUIDs is 8, 9, a or b. Once you know where to look you can identify a v4 UUID at a glance, and you can confirm that a value from this generator is well formed before you rely on it.
Version 4, random and everywhere
Version 4 fills the identifier with 122 random bits from a cryptographic source. It needs no coordination, no timestamp and no hardware address, which makes it the default choice for primary keys, correlation IDs, idempotency keys and file names. Because the values carry no meaning, they never leak when a record was created or where. The trade off is that random keys scatter across a database index rather than clustering, which can hurt insert performance on very large tables.
Versions 1, 5 and 7 at a glance
Version 1 encodes a timestamp and a node identifier, so the IDs sort by creation time but can reveal the machine and the moment they were made. Version 5 is deterministic, hashing a namespace and a name so the same input always yields the same UUID, which is handy for stable IDs derived from a URL or a filename. Version 7 is a newer time ordered format that puts a millisecond timestamp in the high bits, giving the sortability of v1 with the privacy and randomness of v4 in the lower bits. This tool focuses on v4 because it is the safest general default.
Choosing a version for your project
Reach for version 4 when you simply need a unique label and you do not care about ordering, which covers most application code. Prefer version 7 when you want database keys that insert in roughly time order to keep an index tight, if your platform supports it. Use version 5 when you need the same name to map to the same UUID every time, such as deriving a stable ID from an email or a path. Avoid version 1 in public identifiers when the embedded timestamp or node address would be sensitive.