UUID Generator
Version 4 UUIDs, correct to RFC 9562, as many as you need.
Version 4, drawn from your browser’s cryptographic random source. 122 of the 128 bits are random; the other six identify the version and variant, which is why every one of these has a 4 opening the third group.
How the UUID Generator works
Version 4 UUIDs, generated in your browser from its cryptographic random source, in whichever shape your target wants: standard, uppercase, wrapped in braces for the Microsoft convention, or with the hyphens stripped. Up to five hundred at a time, with a copy-all button for when you are seeding a table.
Also known as: guid generator · uuid v4 generator · bulk uuid generator · random guid online · uuid without hyphens
What makes a v4 UUID a v4
A version 4 UUID is often described as 128 random bits, and it is not quite. Six of those bits are spoken for. The high four bits of the seventh byte hold the version number, which is why every v4 UUID has a 4 as the first character of its third group. The top two bits of the ninth byte hold the variant, which is why the fourth group always begins with 8, 9, a or b. Those six bits are fixed by RFC 9562, the specification that replaced RFC 4122 in 2024.
That leaves 122 random bits, and it is worth writing the arithmetic out because the number surprises people. To reach a fifty percent chance of a single collision you need roughly two to the power 61 UUIDs, which is about 2.3 quintillion. Generating a billion every second, that is around eighty-five years.
Which means the realistic failure is never the arithmetic. It is a generator drawing from a weak random source, at which point the 122 bits are notional. This one uses the browser's cryptographic random source and refuses to produce anything at all if that is unavailable, rather than falling back to Math.random the way a good many online generators quietly do.
UUIDs as database keys
Using a v4 UUID as a primary key is a real trade rather than a mistake. The benefit is that identifiers carry no information: an external party seeing one learns nothing about how many rows you have or when the row was created, which sequential integers give away immediately.
The cost is index behaviour. A v4 UUID is random, so consecutive inserts land at random points in a B-tree rather than at the end of it. Pages split, the index fragments, and the working set that has to stay in memory is the whole index rather than its tail. On a high-write table that is a measurable slowdown, and it gets worse as the table grows.
The usual answers are to keep a sequential integer as the internal key and expose a UUID externally, or to use an ordered UUID variant. Version 7, standardised in RFC 9562 alongside v4, puts a millisecond timestamp in the leading 48 bits, so identifiers sort roughly by creation time and insert at the end of the index while remaining unguessable in their random tail. If you are choosing a key format for a new write-heavy table, v7 is usually the better answer; v4 remains right for anything where the identifier must reveal nothing at all, including when it was made.
The formats, and who asks for them
The standard form is 36 characters: 32 hexadecimal digits in five hyphenated groups of 8, 4, 4, 4 and 12. Lowercase is what RFC 9562 specifies for output, and parsers are required to accept either case on input.
The braced form is Microsoft's convention, where the same value is called a GUID and written wrapped in curly brackets. It is what you will see in the Windows registry, in COM class identifiers and in a good deal of .NET tooling, and pasting a standard-form UUID where a braced one is expected is a common source of a mystifying parse error.
Stripping the hyphens gives a 32-character string that fits neatly in a fixed-width column, appears in URLs where the hyphens would be noise, and is what several APIs return. It is the same 128 bits either way; only the punctuation differs, and every parser worth using will accept the compact form.
Frequently asked questions
What makes a UUID version 4?
Two fixed fields. The high nibble of the seventh byte holds the version, which is why every v4 has a 4 opening the third group, and the top two bits of the ninth byte hold the variant, which is why the fourth group always starts with 8, 9, a or b. That leaves 122 random bits rather than 128.
Will I ever get a collision?
Not in any practical sense. With 122 random bits you would need to generate around a billion UUIDs a second for about eighty-five years before the chance of a single collision reached fifty percent. The realistic risk is not the arithmetic, it is a generator using a weak random source, which is why this one uses the cryptographic API and refuses to run without it.
What is the difference between a UUID and a GUID?
Nothing, for practical purposes. GUID is Microsoft's name for the same 128-bit identifier, usually written in braces. The braced format here is exactly that.
Should I use a UUID as a database primary key?
It depends on the index. A v4 UUID is random, so inserts land all over a B-tree and fragment it, which is why high-write tables often use an ordered variant like v7 or a separate sequence instead. As an external identifier that never reveals how many rows you have, v4 is exactly right.
Are these actually unique?
They are unpredictable and drawn from a space large enough that repetition is not a practical concern, which is what people mean by unique here. Nothing checks them against a list, because there is no list to check against, and any generator claiming otherwise is not telling you the whole story.
Related calculators
Password Generator
Cryptographically random, generated in your browser, never sent anywhere.
OpenRandom Number Generator
Pick a range, get numbers nobody can predict.
OpenBarcode Generator
EAN, UPC, Code 128 and ITF, printed at true size.
Open