Generate UUIDs in any version, in bulk, in the format you need, and copy them with one click. Paste one you already have and the page will read back its version and the timestamp inside it. Everything happens in your browser; no value is ever sent to a server.
Paste a UUID you already have and it reads back the version, the variant and, where there is one, the timestamp inside. Braced, urn:uuid: prefixed, upper case and unhyphenated forms are all accepted.
If you are not sure what you need, stay on v4. Pick v7 for database primary keys, and v5 when the same input must always give the same identifier.
One identifier, or up to 500 at once. Generation happens in your browser, so there is nothing to wait for.
Upper case, no hyphens, braces and the urn:uuid: prefix are switches; the list is rewritten as you toggle them.
Copy as a plain list, a JSON array, CSV or a ready-made SQL INSERT — or download it as a .txt file.
A UUID (Universally Unique Identifier) is a 128-bit identifier. Its purpose is to make the chance of two systems that know nothing about each other producing the same number effectively zero, without either of them asking a central authority. You do not have to ask a database server for the next number; whatever creates the record mints the identifier itself.
GUID (Globally Unique Identifier) is what the same thing is called in the Microsoft world. There is no technical difference between them; Microsoft tools simply tend to write the value in braces and upper case. That is exactly what the format switches on this page are for.
The standard was updated in 2024 by RFC 9562, which replaced the older RFC 4122. The new text added versions 7 and 8, introduced the Max value alongside NIL, and recommended v7 over v1 and v5 over v3. This tool follows RFC 9562.
| Version | What does it contain? | When to use it |
|---|---|---|
| v4 | 122 bits of randomness | The default choice. It carries no information and leaks nothing. If you are not sure what you need, pick this. |
| v7 | Unix timestamp + randomness | Database primary keys. Because it sorts in creation order, it keeps the index from fragmenting. |
| v1 | Timestamp + node identifier | Only when an older system expects v1. For new work, v7 is recommended instead. |
| v5 | Namespace + name (SHA-1) | When the same input must always give the same identifier — deriving a stable identifier for a URL, for instance. |
| v3 | Namespace + name (MD5) | The same job as v5 with the older hash. Only when something expects MD5. Otherwise, v5. |
| NIL / Max | All 0 / all f | Two special constants meaning “no value” and “upper bound”. |
v4 is fully random, so every identifier lands somewhere arbitrary in the index. In a B-tree that means each new row touches a different page: pages split, more of the index has to stay in cache, and write performance degrades as the table grows. With an auto-incrementing integer every row appends at the end and a single page stays hot.
v7 was designed to close exactly that gap. Its first 48 bits are a Unix timestamp in milliseconds, so identifiers made one after another take nearby values and append to the index in order. It combines the UUID's ability to be generated anywhere with the index behaviour of an incrementing integer.
The cost is that v7 writes the moment of creation into the identifier. If you need to hide when a record was created, v7 gives it away, and v4 is the right choice. Paste a v7 into the decoder on this page and you will see how easily it comes back out.
In v4, 122 bits are random, which comes to 5.3 × 10³⁶ possible values. You would have to generate billions of UUIDs before the chance of a collision became meaningful — a number nobody reaches in practice. This is why UUIDs offer uniqueness as a negligible probability rather than a guarantee.
The real risk is not the maths but poor randomness. An application built on a weak random number generator can collide far more often than the theory suggests. This page uses the browser's cryptographic generator (crypto.getRandomValues) and never falls back to Math.random.
The name-based versions are a different matter: v3 and v5 are deterministic on purpose. The same namespace and name always give the same identifier — not a flaw, but the whole reason those versions exist.
v4, v7, v1, v5 and v3, plus the NIL and Max constants. What each one is for appears the moment you select it.
Enter a count and take the list. Because it happens in your browser there is nothing to wait for and no load on any server.
A plain list, a JSON array, CSV, or a ready-made SQL INSERT. You can also download it as .txt.
It reads back the version, the variant and, for v1, v6 and v7, the timestamp inside. If the value is invalid it says why.
A v1 classically carries a MAC address. Here it cannot: a browser has no way to read one, so the node is random and marked as the standard requires.
Both generating and decoding happen entirely in your browser. Neither what you generate nor what you decode is recorded anywhere.
A UUID is a 128-bit universally unique identifier. It is designed to be generated without asking any central authority for the next number: two systems that know nothing about each other can generate identifiers at the same moment and the chance of a collision is negligible.
There is no technical difference; GUID is Microsoft's name for the same thing. Only the writing differs: Microsoft tools usually print the value in braces and upper case. The format switches on this page produce either form.
If you are unsure, v4. If it is going to be a database primary key, v7 — it is time-ordered, so it does not fragment the index. If you need the same input to always give the same identifier, v5. v1 and v3 exist only for compatibility with older systems; RFC 9562 recommends v7 and v5 instead.
In v4, 122 bits are random, which is 5.3 × 10³⁶ possible values. You would have to generate billions of identifiers before the chance of a collision became meaningful. The real risk is not the maths but a weak random number generator; this tool uses the browser's cryptographic one.
Because v4 is fully random, every new row lands somewhere different in the index; pages split and write performance degrades as the table grows. The first 48 bits of a v7 are a timestamp, so consecutive identifiers append in order. The cost is that the creation time can be read back out of the identifier.
In classic v1 generation, yes — the node field is the machine's MAC address. There is no such risk here, because a browser cannot read a MAC address. The node is generated randomly with the multicast bit set as the standard requires, so it can never be mistaken for a real interface.
Because they are meant to. These two versions derive an identifier by hashing a namespace together with a name, so the same input always gives the same output. That is what makes them useful for deriving a stable, repeatable identifier for a URL or an email address. It is also why the count control is hidden for them.
PostgreSQL has a native uuid type that takes 16 bytes — smaller and faster than storing text. MySQL has no native type; CHAR(36) is readable while BINARY(16) takes less than half the space. Whichever you pick, keep the format consistent across every row.
NIL is the all-zero special value, used to mean "no value" — a placeholder standing in for null. Max is its all-f counterpart, defined by RFC 9562, used as an upper bound in ranges. Neither identifies a real object.
No. Both generation and decoding happen entirely in your browser; the page makes no request to the server for either. Nothing you generate, and nothing you paste in to decode, is written anywhere.