UUID Generator

Choose the options first, then press the button: the list is only created when you ask for it, and changing an option afterwards does not rewrite what is already on screen.

1. Pick a Version: v4 (random) or v7 (time-ordered).
2. Set How many, from 1 to 1000. The default is 5.
3. Tick Uppercase if your schema or style guide wants capital hex digits.
4. Tick Remove dashes for a compact 32-character string, handy for file names or systems that store plain hex.
5. Press Generate UUIDs, then Copy to put the whole list on the clipboard, one UUID per line, or Download .txt to save it as a file.

A typical batch of five looks like five lines of 36 characters each; with Remove dashes ticked each line becomes 32 characters, and with Uppercase ticked the letters a to f become capitals. The values themselves are unchanged by those two options, so a system that stores UUIDs as plain hex will read the compact form as the same identifier.

Version 4 values come from crypto.randomUUID() where the browser provides it, otherwise from crypto.getRandomValues(). Version 7 values are built from the current time in milliseconds plus crypto.getRandomValues(). Nothing is requested from or sent to a server. Other versions (1, 3, 5, 6 and 8), braces and namespace UUIDs are not offered.

Test data, mock API responses, correlation IDs for log lines and idempotency keys for payment retries are all common reasons to need a batch of identifiers quickly. Whatever the use, it helps to know what the characters mean.

A UUID is a 128-bit number written as 32 hexadecimal digits in five groups, 36 characters with the hyphens: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx. The digit M is the version and N carries the variant, which is 8, 9, a or b for both versions here. Two example layouts, shown for format only:

In the version 7 example the first 12 hex digits, 017f22e279b0, decode to 22 February 2022 at 19:22:22 UTC. That is why v7 values sort by creation time and v4 values do not. Microsoft calls the same structure a GUID, and the two names are interchangeable. The specification is RFC 9562, which replaced RFC 4122.

A version 4 UUID has 2^122 possible values, about 5.3 x 10^36. You would need to create roughly 2.7 x 10^18 of them before the chance of one duplicate reached fifty percent, so accidental collisions are not a practical concern as long as the random source is sound.

• Primary keys across services. Clients can create keys offline without asking the database for the next number.
• Public identifiers. Unlike auto-increment integers, they do not reveal how many records exist.
• Storage. A UUID needs 16 bytes as binary but 36 as text, so use a binary or native UUID column where the database has one.

Random v4 keys scatter inserts across a B-tree index, which hurts write speed and cache use on large tables. Version 7 values are larger than earlier ones, so inserts land near the end of the index. One honest limit: this tool does not add a counter, so values created within the same millisecond may come out in any order relative to each other, so a big batch is only sorted to the nearest millisecond. Choose v4 when creation time must stay hidden, and treat any UUID as an identifier, not a secret; for secrets use the strong password generator. To record when a v7 value was made, convert its prefix with the Unix timestamp converter, and for fingerprints of content use the hash generator.

If you only need a few for a test fixture, the default of five is enough. To seed a table, ask for up to 1000 and press Generate UUIDs again for more, since each press makes a fresh set. Remember that a dashed UUID is 36 characters as text, so a 32-character column would cut it short.