Generator Tools
Generate useful identifiers, passwords, placeholder text, and URL-friendly slugs in your browser.
Tools
UUID v4 vs. time-based versions
UUID Generator produces version 4 IDs: 122 bits of cryptographically secure randomness, with no timestamp or machine identifier embedded anywhere in them. That's different from time-based versions like v1 or the newer v7, which put a timestamp in the leading bits so that IDs generated later sort after ones generated earlier. Time ordering helps database index performance at scale, but it also means the ID reveals roughly when it was created, which v4's pure randomness never does.
UUID v7, briefly
UUID v7 is a newer, standardized version built specifically to be sortable: it starts with a millisecond-precision timestamp and fills the rest with random bits. Generated in sequence, v7 IDs come out in roughly chronological order, which some databases index more efficiently than the scattered order v4 produces. It's a reasonable choice when insertion order matters for performance; this generator creates v4, the right default when you specifically don't want creation time encoded in the identifier.
Why uniqueness is probabilistic, not guaranteed
No fixed-length random ID can offer an absolute mathematical guarantee against collision, there are only ever finitely many possible values. What UUID v4 offers instead is a collision probability low enough to disregard: with 122 random bits, generating a billion UUIDs every second for roughly 85 years straight still wouldn't reach a 50% chance of a single collision. In practice that risk is far below ordinary hardware failure, which is why UUIDs are treated as unique for essentially any real-world workload.
Frequently asked questions
- What is a UUID, and why use one instead of an incrementing ID?
- A UUID (Universally Unique Identifier) is a 128-bit value that any system can generate on its own, with no central authority or database handing out the next number. That's the advantage over an auto-incrementing integer: two services, two database shards, or an offline client can each mint IDs independently with no coordination and no risk of two systems handing out the same value.
- What makes UUID v4 different from time-based versions like v1 or v7?
- V4 is pure randomness: 122 bits of random data with no timestamp or machine identifier embedded. Time-based versions like v1 and v7 encode the creation time in the leading bits, which means IDs generated later sort after ones generated earlier. That ordering is convenient for database indexing, but it also means the UUID reveals when it was created, something v4 never does.
- What is UUID v7, at a high level?
- A newer, standardized UUID version that leads with a millisecond-precision timestamp followed by random bits. Because the timestamp comes first, v7 UUIDs generated in sequence sort in roughly chronological order, which helps database index performance compared to the effectively random ordering of v4. This generator produces v4 IDs; if an application specifically calls for time-ordered identifiers, that's the version to look for elsewhere.
- If UUIDs aren't guaranteed unique, why do we treat them as unique?
- No random scheme offers a mathematical uniqueness guarantee, only a collision probability low enough to ignore in practice. For UUID v4's 122 random bits, generating a billion UUIDs a second for about 85 years straight would still leave less than a 50% chance of ever seeing a single collision, a risk far below routine hardware failure. Treat it as unique for any realistic workload; formally, it's a near-certainty rather than a guarantee.
- When should I use a UUID instead of a shorter ID?
- When IDs need to be generated in more than one place without coordination, like client-side, across services, or offline, or when you don't want an ID's format to leak how many records exist or in what order. If you only need a short, human-typeable code, or IDs are always assigned by a single database that already guarantees uniqueness, a UUID is usually more than you need.