UUID generator
Five random version-4 UUIDs are already waiting below. Change the count, tick uppercase or braces if the system you are feeding wants them that way, then copy the lot in one press. Every value comes from your browser's cryptographic random source.
Nothing is uploaded and nothing is stored. The identifiers are made inside this tab and are gone the moment you close it — no server ever sees a value you copied from here.
How these UUIDs are generated
A version-4 UUID is 128 bits, of which 122 are random. The other six are fixed markers: four bits declare the version and two declare the variant — the layout rules the rest of the value follows. Those bits are why every v4 UUID has a 4 at the start of the third group and one of 8, 9, a or b at the start of the fourth. If you are squinting at an identifier trying to work out where it came from, those two characters are the tell.
Where your browser offers crypto.randomUUID() this page calls it directly. Where it does not — older Safari, or any page not served over HTTPS — it falls back to crypto.getRandomValues() to draw sixteen bytes and then sets the version and variant bits by hand: b[6] = (b[6] & 0x0f) | 0x40 and b[8] = (b[8] & 0x3f) | 0x80. Both routes pull from the same cryptographically secure source; the fallback just does the bit work that randomUUID does internally. Math.random is never involved, and that matters — it is fast, it is seeded from something a determined attacker can reason about, and it has no business anywhere near a value someone might try to guess.
The count is capped at 100 per press, because a hundred lines is already more than anyone reads and the copy button does not care how many there are. Type 0 or leave the box empty and you get one. The two tick boxes are display only: they re-render the identifiers already on screen rather than making new ones, so you can copy the same batch in lowercase for a config file and again in brace-wrapped capitals for a Windows registry key.
Questions people ask
What is the difference between UUID v1, v4 and v7?
Version 1 encodes a timestamp and the machine's MAC address, so the values sort roughly by creation order but quietly publish where and when they were made. Version 4 is random throughout: no ordering, nothing leaked, which is why it became the default everywhere. Version 7, standardised in RFC 9562 in 2024, puts a 48-bit millisecond timestamp at the front and randomness behind it, so values sort by creation time while staying unguessable. If you are inserting millions of rows into a clustered index, v7 is worth the migration. For everything else v4 is the right default, and v4 is what this page produces.
What are the real odds of two random UUIDs colliding?
122 random bits give about 5.3 × 10^36 possible values. By the birthday bound you would need roughly 2.71 × 10^18 — 2.71 quintillion — version-4 UUIDs before there is an even chance that any two of them match. Generating a billion every second, that is about 86 years of continuous work. At a scale you might actually reach, 103 trillion UUIDs carry around a one-in-a-billion chance of a single duplicate. A collision in your database is far less likely than a bug in the code that writes them, so spend the worry there instead.
Are these safe to use as database keys or session tokens?
As database keys, yes — that is the ordinary use. As session tokens, the entropy is fine: crypto.randomUUID is backed by the platform's cryptographically secure pseudorandom generator, so each value carries 122 unguessable bits, comfortably past the 64-bit floor OWASP sets for session identifiers and close to the 128 bits it recommends. The catch is not the randomness but the location. A session id has to be minted by the party that will trust it; a token generated in a browser and posted to a server is a value the client chose. Use this page for identifiers you need to read, paste and seed data with, not for issuing credentials.
Why do some systems print UUIDs in capitals or wrap them in braces?
Microsoft's COM tooling has written GUIDs as {2F1C3E4A-…} in capitals since the early nineties, and the Windows registry, the .NET "B" format specifier and Visual Studio project files still expect that shape. RFC 9562 says to emit lowercase and accept either case on input, so plain lowercase without braces is the safer default when you have a choice. The braces and the capitals are presentation, not content — the same 128 bits either way.
Should I store a UUID as text or as bytes?
As text it is 36 characters; as bytes it is 16. PostgreSQL has a native uuid type that stores the bytes and prints the hyphenated form, so use it. MySQL has no such type: BINARY(16) with UUID_TO_BIN() is less than half the size of CHAR(36) and indexes better, while CHAR(36) is far easier to read over a shell. SQL Server has uniqueidentifier. The trap worth naming is storing the text form under a case-sensitive collation and then letting two services insert different cases — that is how one identifier becomes two rows.