Every UUID is a 128-bit number, conventionally displayed as 32 hexadecimal characters in the pattern xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx. The M digit tells you the version (1, 3, 4, 5, or 7), and the first bits of N tell you the "variant" (almost always the standard RFC 4122 variant). You don't need to memorize this — just know that the version digit is what determines how the ID was actually generated, and that changes what it's safe to use for.
Generated from the current timestamp (100-nanosecond precision) plus the network card's MAC address, plus a small random "clock sequence" to avoid collisions if the clock moves backward. This makes v1 IDs sortable by creation time and traceable to a specific machine — which is exactly the problem: it leaks your server's MAC address and the precise moment the ID was created. Rarely a good choice for anything public-facing today.
122 bits of cryptographically secure randomness (the remaining 6 bits are fixed to mark the version/variant). No timestamp, no MAC address, no pattern to reverse-engineer. This is the default most languages and frameworks use when you call uuid() without arguments — crypto.randomUUID() in JavaScript, uuid4() in Python, gen_random_uuid() in Postgres. Use it whenever you just need a safe, private, collision-resistant ID and don't care about sort order.
The newest version (standardized in 2024). The first 48 bits are a millisecond Unix timestamp, and the rest is random. This gives you the privacy of v4 (no MAC address, no way to reconstruct exact nanosecond timing) combined with the practical benefit of v1: IDs sort roughly in creation order. That matters a lot for database performance — inserting monotonically-increasing keys into a B-tree index avoids the page-splitting and fragmentation that fully random v4 keys cause at scale. If you're choosing a UUID format for a new high-write-volume table today, v7 is usually the better call.
These hash a namespace + a name (v3 uses MD5, v5 uses SHA-1) to produce the same UUID every time for the same input. Useful when you need a stable, reproducible ID derived from something else — e.g. generating a consistent UUID from a URL or email address without a database lookup. Not random, and not meant to be.
| Version | Sortable by time? | Leaks info? | Best for |
|---|---|---|---|
| v1 | Yes | MAC address + exact timestamp | Legacy systems only |
| v4 | No | Nothing | General-purpose IDs, tokens, public-facing keys |
| v7 | Yes (coarse, ms) | Approximate creation time only | Database primary keys at scale |
| v3/v5 | No | Nothing (but deterministic) | Reproducible IDs from a known input |
If you're not sure which to pick: use v4. It's the safe, general-purpose default supported everywhere. Only reach for v7 once you've confirmed insert performance on a UUID-keyed table is actually a bottleneck, and only reach for v1 if you're integrating with a legacy system that specifically requires it.
Bulk-generate up to 50 random UUID v4 identifiers, free and instant, entirely in your browser.
Open UUID Generator →uuidv7() support in version 18. For earlier Postgres and for MySQL, you can generate v7 UUIDs in application code (most UUID libraries added v7 support in 2024–2025) and store them as a standard UUID/CHAR(36) column.