UUID generator

Generate RFC4122 v4 UUIDs in any count or format.

Count Uppercase No dashes

You need a hundred identifiers to seed a test fixture, or one key for a record that several services will create independently without asking a database for the next number. This produces version 4 UUIDs - the all-random kind - in whichever shape your column or config file expects.

How it works

The controls

Control	What it does
Count	How many to produce, from 1 to 100, one per line
Uppercase	Prints A-F instead of a-f
No dashes	Strips the hyphens, leaving 32 hex characters

Output regenerates whenever you change a setting, and Copy puts the whole block on the clipboard. Case is worth a thought: RFC 4122 says UUIDs are case-insensitive when compared as UUIDs, but most string comparisons in application code are not, so pick one form and stay with it across your codebase.

What a version 4 UUID is made of

It is 128 bits, written as 32 hex digits in an 8-4-4-4-12 layout. Of those bits, 122 are random; 4 mark the version and 2 mark the variant. You can read both off any output from this page:

The 13th hex digit is always 4 - that is the version.
The 17th is 8, 9, a or b - that is the variant.

Generation uses crypto.randomUUID() where the browser provides it, otherwise crypto.getRandomValues() with those bits set manually. Both draw from a cryptographically secure source, and both run entirely in your browser - no identifier is transmitted.

Storing them, and the usual mistakes

Column type. In MySQL, BINARY(16) with UUID_TO_BIN() / BIN_TO_UUID() is compact and keeps indexes small; CHAR(36) is bulkier but readable in query output. Note that the second argument to UUID_TO_BIN() reorders time fields for version 1 and does nothing useful for version 4.
Primary keys. Version 4 values are random, so consecutive inserts land in unrelated places in a clustered index, causing page splits and a larger working set. It works, but on write-heavy tables consider a time-ordered identifier such as UUIDv7 or ULID, or keep an internal auto-increment key and expose the UUID.
Not a secret. The randomness is strong, but UUIDs end up in URLs, logs and error reports. Treat them as identifiers, not as authentication tokens.

Terms explained

UUID: A 128-bit identifier designed to be generated independently in many places without coordination.
Version 4: The variant whose bits are essentially all random, as opposed to version 1 (time and MAC address) or version 7 (time-ordered).
RFC 4122: The specification that defines the UUID layout, versions and text format.
Variant bits: Two bits that mark which UUID layout is in use, visible as the 8, 9, a or b at the 17th hex digit.
Hex: Base-16 notation using 0-9 and a-f. Each hex digit stands for four bits.

Frequently asked questions

Are these really unique?

In practice, yes. With 122 random bits there are about 5.3 x 10^36 possible values, so two independently generated version 4 UUIDs colliding is not a risk worth engineering around - provided the source of randomness is sound, which it is here.

Are they generated on your server?

No. They are produced in your browser by the built-in cryptographic random functions and never sent anywhere. You can disconnect from the network and the page will still work.

Should I store them as CHAR(36) or BINARY(16)?

BINARY(16) uses less than half the space and keeps indexes smaller, which matters on large tables; CHAR(36) is easier to read when you are looking at query results by hand. MySQL 8 gives you UUID_TO_BIN() and BIN_TO_UUID() to move between the two.

Is a UUID a good primary key?

It can be, but random version 4 values scatter inserts across a clustered index and fragment it. If the table takes heavy writes, either use a time-ordered identifier such as UUIDv7 or ULID, or keep a sequential internal key and use the UUID as the public one.

What is the difference between v1, v4 and v7?

Version 1 is built from a timestamp and a hardware address, so it leaks both. Version 4 is random, which is what this tool produces. Version 7 puts a timestamp in the leading bits followed by random ones, so the values sort by creation time - useful as a database key.