What is a UUID?
A UUID (universally unique identifier), sometimes called a GUID, is a 128-bit value written as 32 hexadecimal digits in five hyphen-separated groups, such as 550e8400-e29b-41d4-a716-446655440000. Its purpose is to let many independent systems each mint identifiers that are effectively guaranteed not to collide, without coordinating through a central authority or a shared database sequence to hand out the next value.
That property is what makes UUIDs so useful in modern architectures: any service, device, or client can generate one on the spot and trust that it will not clash with an identifier created somewhere else. This decentralization is the whole point — identity is decided at the moment of creation, not negotiated with a database afterwards.
Version 4 vs. version 1 (and version 7)
The UUID versions differ in how the bits are filled. Version 1 encodes a timestamp and the generating machine's network address, which makes v1 UUIDs roughly sortable by creation time but can leak information about where and when they were made. Version 4, which this tool generates, fills 122 of the 128 bits with random data, carrying no embedded metadata at all.
A newer version 7 combines a millisecond timestamp with random bits to produce identifiers that are both unguessable and time-ordered, which is friendly to database indexes. Choose v4 when you simply need an opaque unique ID, and consider v7 when insertion order and index locality matter. Mixing versions within a single system is best avoided, since it undermines any ordering guarantees you were relying on and makes identifiers harder to reason about.
UUIDs vs. auto-increment IDs and collision odds
Auto-increment integers are compact, naturally ordered, and efficient as primary keys, but they require a central database to allocate them and they expose how many records exist, which can be a privacy or security concern. UUIDs trade a little size and index locality for decentralized generation and non-enumerability — you cannot guess the next record's ID.
The collision risk for version 4 UUIDs is negligible: with 122 random bits you would need to generate on the order of a billion UUIDs per second for decades before a single collision became likely. For every practical purpose they are unique, which is why they are trusted for primary keys, correlation and request IDs, and idempotency keys. The trade-offs are real but manageable, and for most applications the operational simplicity of generating IDs anywhere outweighs the modest storage and indexing cost. When ordering genuinely matters, reaching for version 7 recovers most of that index efficiency without giving up decentralized generation.