JSON Formatter
Pretty-print, validate and minify JSON with precise error positions.
Developer & Security
UUID Generator
Version 4 and version 7 UUIDs from the browser’s crypto source.
What it does. A UUID is a 128-bit identifier that can be generated independently anywhere without coordination and still be effectively unique. Version 4 is 122 random bits. Version 7, standardised in RFC 9562 in 2024, puts a millisecond timestamp in the high bits so identifiers sort chronologically — which matters a great deal if they are used as database primary keys.
Runs in your browserNothing uploadsNo signupWorks offline
How to use UUID Generator
- Choose version 4 for pure randomness or version 7 for time-ordered keys.
- Set how many you need and whether to include hyphens or uppercase.
- Copy the list. Generation uses crypto.getRandomValues locally.
Version 4 or version 7?
Use v7 for anything stored in a database index, and v4 for everything else.
A v4 UUID is random, so consecutive inserts land in random positions in a B-tree index. That fragments the index and slows writes as the table grows — the well-documented reason teams abandoned UUID primary keys for years.
A v7 UUID starts with a 48-bit millisecond timestamp, so newly generated values sort after older ones and inserts append to the end of the index instead of scattering. It keeps the independence of a UUID and removes the reason not to use one as a key.
The trade is that a v7 UUID leaks its creation time to anyone holding it. That is usually harmless for a row ID and occasionally not — an unguessable token for a password reset should be v4.
How unique is unique
A v4 UUID has 122 random bits. To reach a 50% chance of a single collision you would need to generate about 2.7 × 10^18 of them.
Put concretely: at a billion UUIDs per second it takes roughly 85 years to reach even a one-in-a-billion chance of any collision. Collision is not a risk worth engineering around.
What is worth checking is the randomness source. A UUID built from Math.random is not cryptographically random and has been the cause of real, guessable-token vulnerabilities. This tool uses crypto.getRandomValues, and modern browsers also expose crypto.randomUUID for v4 directly.
Format details
| Part | v4 | v7 |
|---|---|---|
| Length | 36 chars with hyphens | Same |
| Version nibble | 4 | 7 |
| High bits | Random | 48-bit ms timestamp |
| Sortable | No | Yes, by creation time |
| Leaks time | No | Yes |
Frequently asked questions
What is the difference between UUID and GUID?
Nothing meaningful. GUID is Microsoft’s name for the same 128-bit identifier. The formats are interchangeable; only the terminology differs by ecosystem.
Should I use a UUID as a database primary key?
Version 7, yes. Version 4 fragments B-tree indexes because random values scatter across the index on insert, which slows writes as the table grows. V7’s timestamp prefix makes inserts append instead.
Can two UUIDs ever be the same?
In theory. In practice a v4 UUID has 122 random bits, so reaching a 50% chance of one collision needs about 2.7 × 10^18 values. The real risk is a weak randomness source, not the maths.
Is a UUID secret?
A v4 UUID from a cryptographic source is unguessable and can serve as a token. A v7 UUID reveals its creation time and is partly predictable, so it should not be used where unguessability matters.
Are these generated on your server?
No. Generation happens in your browser using Web Crypto. Nothing is sent anywhere, which is why the page works offline.