UUID v4 in Practice: How Random IDs Work and When to Use Them
By the Super Simple Digital Tools Team · Updated June 2026
A UUID is a 128-bit number, but you almost always meet it as a 36-character text string split into the 8-4-4-4-12 groups. Of those 128 bits, version 4 reserves a handful to mark the version and variant and fills the other 122 with randomness. That single design choice is what makes v4 so easy to work with: there is no clock to read, no node identifier to configure, and no coordination between machines. Any client, anywhere, online or offline, can produce one and trust it will not clash with anyone else's.
The generation step is mechanical. The tool requests 16 random bytes from a cryptographically secure generator, then sets four bits of one byte to encode version 4 and two bits of another to encode the RFC variant. Everything else is left untouched. Decode any v4 value and you will see the fixed 4 in the version position and an 8, 9, a, or b in the variant position; the rest is noise. Because nothing about the host or the timestamp is encoded, a v4 UUID reveals nothing about who or what created it, which is a real privacy advantage over the older version 1 format.
It helps to put the collision math in perspective rather than just calling it impossible. The birthday-paradox calculation says you need around 2.71 x 10^18 generated UUIDs before the probability of any two matching reaches 50%. Generating a billion every second, that milestone is roughly 86 years away, and most applications never create more than a few billion identifiers across their entire lifetime. The one assumption baked into those numbers is good entropy: the guarantee depends on a strong random source, so a weak or low-entropy generator is the only realistic way to get into trouble.
Choosing v4 versus its siblings comes down to what you need from the ID. Version 1 stitches together a timestamp and the machine's MAC address; it is sortable but leaks hardware details and is largely avoided today. Version 7, standardized in RFC 9562 in 2024, leads with a 48-bit millisecond timestamp followed by random bits, so values sort by creation time and play nicely with database B-tree indexes. Version 4 trades that ordering for pure randomness, which is exactly what you want when you do not need sortability and would rather not embed a timestamp at all.
In real codebases, v4 UUIDs end up everywhere: primary keys when you want client-generated IDs, idempotency keys that let an API safely retry a request, correlation IDs that trace one call across many services, file and object names that will never collide, and stable handles for records that exist before they are saved. Bulk generation is the common workflow here: developers grab dozens or hundreds at once to seed test data, populate fixtures, or pre-allocate identifiers. Generate the batch, paste it where you need it, and move on.
- Generating a batch for a test database or fixtures? Use the bulk option, then paste the whole block into your seed script instead of running the tool once per row.
- Validate a UUID by eye: confirm 36 characters, four hyphens in the 8-4-4-4-12 pattern, a 4 in the 13th digit, and 8/9/a/b in the 17th digit for a true v4.
- Storing many UUIDs in MySQL? Prefer BINARY(16) over CHAR(36); it is far more index- and space-efficient. PostgreSQL has a native 16-byte uuid type, so use that.
- If you need IDs that sort by creation time for index performance, pick UUID v7 instead; reserve v4 for cases where unpredictability matters more than ordering.