UUID Generator
Version 4 and version 7, generated in this tab by your browser's cryptographic random source. Nothing is sent anywhere.
Which version should you use?
There are eight versions in the standard and you almost certainly want one of two.
| You are… | Use | Why |
|---|---|---|
| Giving something an id, anywhere | v4 | Purely random, leaks nothing, universally supported |
| Using it as a database primary key | v7 | Time-ordered, so inserts stay at the end of the index instead of scattering |
| Naming a file, a batch or a log line | v7 | The ids sort chronologically on their own, with no extra column |
| Producing a token that must not be guessable | v4 | All 122 non-fixed bits are random; v7 spends 48 of them on a readable clock |
| Maintaining something that already uses v1 | Leave it | But do not start anything new on v1 — see below |
RFC 9562, which replaced RFC 4122 as the UUID standard, puts it plainly: implementations should use version 7 in preference to versions 1 and 6.
Why v7 exists, in one paragraph about databases
A v4 UUID is random across its entire range, so consecutive rows get keys that are nowhere near each other. In a B-tree index that means every insert lands at an unpredictable point in the tree, the database has to pull that page into memory to write it, and the pages it already has cached are rarely the ones it needs. Under steady inserts the index fragments and the write cost climbs.
A v7 UUID puts a millisecond Unix timestamp in its leading 48 bits, so a value made now sorts after one made a second ago. Inserts land at the end of the index, the same few pages stay hot, and the tree grows the way an auto-incrementing integer key would — while still being globally unique and safe to generate on many machines at once.
That is the whole trade. You buy index locality, and you pay for it by making the creation time of every id readable to anyone holding it.
The exact layout
From RFC 9562, a v7 value is:
| Field | Bits | Contents |
|---|---|---|
unix_ts_ms | 48 | Milliseconds since 1 Jan 1970 UTC, big-endian |
ver | 4 | Fixed to 0111 |
rand_a | 12 | Random |
var | 2 | Fixed to 10 |
rand_b | 62 | Random |
So 74 bits of randomness, against 122 in a v4. Still far more than enough to avoid collisions, and worth knowing if you were treating the value as a secret.
Do not start anything new on v1
A version 1 UUID is built from the current time and the network card's MAC address. Both are recoverable from the finished value. Publish v1 identifiers and you are publishing which physical machine minted them and precisely when — which has been used to attribute documents to specific computers before now.
If you want time ordering, that is exactly what v7 is for, without the hardware address. This tool does not generate v1 on purpose.
Where these UUIDs come from
They are generated in this browser tab by crypto.getRandomValues, the
platform's cryptographic random source. This page has no backend, so no value here is
transmitted, logged or stored.
That is worth stating because it is not the norm for this kind of tool. Several of the popular UUID generators produce the value on their server and send it back to you — some of them advertise an API for exactly that. For a throwaway test fixture it makes no difference at all. For anything that has to be unguessable, it means the value existed on someone else's machine and crossed the network before it reached you, and their logs may still have it.
The other half of the same point: a generator that uses Math.random
rather than a cryptographic source produces values that are predictable from earlier
ones. You cannot tell which a page did by looking at the output, which is precisely why
it is worth saying.
Could two ever collide?
A v4 UUID fixes six bits for the version and variant and randomises the other 122. That is about 5.3 × 1036 possible values. Collisions follow the birthday bound, so the number you need before an even chance of one duplicate is roughly the square root of that: about 2.7 × 1018, or 2.7 quintillion.
To put that in proportion: generating a million UUIDs every second, it would take something on the order of eighty thousand years to reach that point.
So in practice the maths is not what fails. What fails is the random source. A
generator seeded weakly, or using Math.random, can repeat values after a
few thousand — not because 122 bits ran out, but because it was never really
using them.
How to use it
Pick a version, set a count, press Generate. The format checkboxes apply immediately to whatever is already in the box, so you can switch to uppercase or braces without generating again. Copy puts the whole output on the clipboard; Download .txt saves it as a file.
Questions
Which UUID version should I use?
Version 4 for a plain unique identifier, version 7 when it will be a database primary key. RFC 9562 says implementations should prefer v7 over v1 and v6. Avoid v1 in anything public — it embeds the generating machine's MAC address and the time it was made.
What makes UUID v7 better for database keys?
It puts a millisecond timestamp in the leading 48 bits, so new values sort after old ones. Rows insert at the end of the index instead of at random points through it, which keeps the recently written pages in memory. A v4 is random across its whole range, so every insert lands somewhere unpredictable and the index fragments.
Can two UUIDs ever be the same?
In principle yes, in practice no. A v4 carries 122 random bits; by the birthday bound you would need around 2.7 quintillion of them for an even chance of a single collision. The realistic failure is a weak random source, not the maths — which is why this page uses crypto.getRandomValues and not Math.random.
Is a UUID safe to use as a secret or a password reset token?
A v4 from a cryptographic source has 122 bits of entropy, which is ample. Two cautions: a v7 exposes its creation time and randomises only 74 bits, and a UUID generated by a website's server rather than in your browser has already crossed the network and may sit in a log.
Are these UUIDs sent to a server?
No. They are produced in your browser tab and this page has no backend, so nothing generated here is transmitted, logged or stored.
What is the difference between a UUID and a GUID?
Nothing that matters. GUID is Microsoft's name for the same 128-bit identifier. Microsoft tooling usually writes them wrapped in braces, which the Braces option reproduces.
Related tools
Browse all Sigma Wire tools - every free tool on the site, grouped by category.