If you're wiring up a new database table or an API response and hit the question "UUID v4 or v7 (or something else)?" — here's how each version actually behaves, when it matters, and how to generate a batch of them without writing a script.
A UUID (Universally Unique Identifier) is a 128-bit value, usually written as 32 hex characters and 4 hyphens (8-4-4-4-12), like 550e8400-e29b-41d4-a716-446655440000. It's defined by RFC 4122 (updated by RFC 9562), and the "version" number embedded in it tells you how it was constructed — random, timestamp-based, or derived from a name. Picking the right version mostly comes down to one question: does this ID need to carry any information beyond "I am unique," and if so, what kind?
UUID versions at a glance
Quick answer v4 is fully random and the most common default. v1 embeds a timestamp plus a node identifier (historically a MAC address). v3/v5 are deterministic — the same namespace and name always produce the same UUID. v7 embeds a millisecond timestamp in a way that keeps sequentially generated IDs sortable, which most v1-style use cases have shifted toward.
Here's a practical comparison of the versions you're likely to run into day to day:
| Version | Basis | Sortable by time? | Typical use |
|---|
| v4 | 122 random bits | No | General-purpose IDs, session tokens |
| v1 | timestamp + node ID | Loosely (not string-sortable) | Legacy systems, distributed ID generation |
| v3 | MD5(namespace+name) | No | Deterministic ID from a name/URL |
| v5 | SHA-1(namespace+name) | No | Deterministic ID (preferred over v3) |
| v7 | 48-bit ms timestamp + random | Yes | Database primary keys |
Note: in a v1-like generator that runs in a browser, there's no real network card to read a MAC address from, so a randomly generated "node" value is used instead — with the multicast bit set, per RFC 4122, to flag that it isn't a genuine hardware address.
v4 vs v7 for primary keys
Quick answer For a new database table, v7 is typically the better default over v4 because its embedded timestamp keeps recently-inserted rows near each other in the index, which is friendlier to B-tree-style indexes under high insert volume.
This is a case where the "most random" option isn't automatically the best one. A v4 UUID is 122 bits of pure randomness, which means each new row you insert lands in a random position in an index — fine at low volume, but it can cause index fragmentation and slower inserts once a table grows large. A v7 UUID's first 48 bits are a millisecond-precision Unix timestamp, so IDs generated close together in time sort close together, similar to how an auto-incrementing integer key behaves, while still being globally unique and generateable client-side without a central counter.
Example scenario (illustrative, not a benchmark): imagine a table that logs one row per user action, inserting thousands of rows per minute during peak hours. With v4 keys, each insert can land anywhere in the index, forcing more random disk I/O as the table grows. With v7 keys, inserts cluster near the "end" of the index because they're roughly time-ordered — this is a commonly cited reason teams migrate new tables to v7, though actual performance impact depends heavily on your database engine, storage, and indexing strategy, so treat this as a general pattern rather than a guaranteed number for your setup.
When to use v3/v5 (name-based, deterministic)
Quick answer Use v3 or v5 when you need the exact same input (a namespace plus a name) to always produce the exact same UUID — useful for de-duplication and re-processing pipelines. v5 (SHA-1) is generally preferred over v3 (MD5) for new work.
Unlike v4 and v7, which are meant to be unpredictable, v3 and v5 are deterministic on purpose. You combine a namespace UUID (RFC 4122 defines standard ones for DNS, URL, OID, and X.500, or you can supply your own) with a name string, hash the combination (MD5 for v3, SHA-1 for v5), and the result is always the same UUID for that exact namespace+name pair. That's genuinely useful when you're importing external records — say, generating an internal ID from each imported URL or filename — and you want re-running the import to produce the same IDs instead of new duplicates every time.
Generating UUIDs in bulk (and validating them)
Quick answer A browser-based UUID generator can produce up to 1,000 UUIDs in one click, in v4/v1-like/v3/v5/v7 forms, with formatting options like uppercase, no hyphens, braces, quoting, and comma-separation — then let you copy, or download as .txt/.csv.
When you need test data — seeding a staging database, generating mock IDs for fixtures, or just producing a batch of GUIDs for a spreadsheet — typing them out one at a time isn't practical. The ToolPico UUID Generator handles this entirely client-side, using the browser's built-in Web Crypto API (crypto.getRandomValues) for randomness, so nothing you generate is ever sent to a server. Beyond raw generation it also includes a validator that decodes a pasted UUID's version and variant, and — for v1, v7, and ULID values, which carry an embedded timestamp — shows the decoded creation time in both UTC and local time. It also converts between UUID, Base64, and hex, and includes copy-paste code examples for Python, JavaScript/Node, Java, C#, Go, PHP, PostgreSQL, and MySQL, plus a standalone ULID generator for cases where a lexicographically sortable, Base32-encoded identifier is a better fit than a UUID.
Need to generate or validate a UUID right now?
Free, runs entirely in your browser — v4, v1-like, v3/v5, v7, and ULID, with bulk generation up to 1,000.
Try the free UUID Generator →
Frequently asked questions
Should I use UUID v4 or v7 for a database primary key?
If insert performance and index locality matter (most relational databases), v7 is usually the better choice because its first 48 bits are a millisecond timestamp, so rows generated close together in time also sort close together in the index. v4 is purely random, which is fine for correctness but can fragment a B-tree index under heavy insert load. Both are collision-resistant enough for practical use.
Is a GUID the same thing as a UUID?
Yes, functionally. A GUID (Globally Unique Identifier) is Microsoft's name for the same 128-bit value defined by RFC 4122. The only common difference is formatting — .NET GUIDs are often written wrapped in braces, like {550e8400-e29b-41d4-a716-446655440000}, while UUIDs are usually written without braces.
When should I use a v3/v5 name-based UUID instead of a random one?
Use v3 or v5 when you need the same input to always produce the same UUID — for example, generating a stable ID from a URL, filename, or external record ID so that reprocessing the same data never creates duplicates. v5 (SHA-1) is generally preferred over v3 (MD5) because SHA-1 has fewer known weaknesses, though for this non-cryptographic identifier use case either is typically acceptable.
Can I generate a large batch of UUIDs at once for a script or test dataset?
Yes. A bulk UUID generator lets you request up to 1,000 UUIDs in one click, choose formatting like lowercase/uppercase, hyphens, quotes, or comma-separation, and then copy the whole batch or download it as a .txt or .csv file — useful for seeding test databases or generating mock IDs for fixtures.
How do I check what version a UUID is, or when it was created?
Paste the UUID into a validator to see its version and variant bits decoded. For v1 and v7 UUIDs (and ULIDs), the validator can also decode the embedded creation timestamp and show it in both UTC and local time, since those formats store time information directly in the identifier.
Related guides
About this guide: This article explains general UUID/GUID concepts and common engineering patterns for informational purposes; it is not a performance benchmark or a recommendation for any specific database or production system. Always test ID strategies against your own workload before adopting them.