UUID Generator Developer Tool

UUID versions, briefly

RFC 4122 defines several ways to generate a UUID, and the version number embedded in the identifier itself tells you which. Version 1 is timestamp-based, combining the current time with the generating machine's MAC address — unique, but it leaks when and where the ID was created, which is rarely desirable. Version 4, the kind this tool generates, is simply 122 bits of randomness (the other 6 bits are fixed to mark the version and variant) with no embedded metadata at all, which is why it's become the default choice for most applications: no coordination, no leaked information, just a random value drawn from a space large enough that collisions are not a practical concern. Version 7 is a more recent addition that combines a millisecond timestamp prefix with trailing randomness, giving IDs that sort chronologically by creation time — useful for database primary keys, where a purely random v4 key causes index fragmentation as new rows insert at random points in the index rather than at the end.

Why collisions aren't a practical concern

A version 4 UUID has 122 random bits, giving 2¹²² possible values — roughly 5.3 × 10³⁶. The commonly cited intuition is the birthday-paradox comparison: you'd need to generate around 2.7 quintillion (2.7 × 10¹⁸) UUIDs before the probability of any single collision reached just one in a billion. Put differently, generating a billion UUIDs a second for a hundred years still wouldn't bring you meaningfully close to a collision. This is why UUIDs work well for independent, uncoordinated ID generation across distributed systems — separate services, offline clients, or database shards can each mint their own IDs without checking in with a central authority, and the odds of two of them colliding are astronomically smaller than the odds of, say, simultaneous hardware failure across your infrastructure.

Common use cases

UUIDs turn up anywhere an identifier needs to be generated without a central counter: primary keys in a database where rows might be created on the client before ever reaching the server, correlation IDs for tracing a request across microservices, session and API tokens, and idempotency keys that let a client safely retry a request (a payment submission, for instance) without a server-side sequence number to check against. Because the client can generate the ID itself before any round trip to the server, UUIDs also let a frontend reference an entity (attach an upload to a not-yet-saved record, say) before it's been persisted anywhere.

UUIDs vs auto-increment IDs

An auto-increment integer primary key is smaller, faster to index, and sorts naturally by insertion order — but it requires a single authoritative counter, which is awkward in distributed or offline-first systems, and it exposes information (row count, creation order, roughly how "big" a table is) to anyone who can see the ID in a URL. A random UUID solves both of those problems at the cost of a larger identifier (16 bytes versus typically 4 or 8), no natural sort order, and worse index locality if used as the primary key in a large table, since a random value inserted into a B-tree index causes page splits scattered across the whole structure rather than appending neatly at the end. Time-ordered UUIDs (v7) or ULIDs are a common middle ground, aiming for the coordination-free generation of a UUID with better index behaviour closer to that of an auto-increment key.