UUID Generator

Using the generator

Five UUIDs are already made when the page opens, in the standard format.

1. Count — how many UUIDs to make, a whole number from 1 to 100. If you type a larger number, the tool makes 100 and shows a message that says so. An empty box, 0, a negative number or a decimal such as 2.7 gives no UUIDs, and a message under the button tells you what to fix.
2. Format — pick one of four styles. You cannot combine them. For example, there is no uppercase with braces.
3. Generate UUIDs — makes a new set and replaces the old one. Changing Count or Format does nothing until you press this button.
4. Copy All — copies every UUID, one per line, with no commas or quotes. The button reads Copied! for a moment when it works.

This is what each format looks like:

Use Standard unless a system asks for something else. The UUID standard (RFC 9562) says to write UUIDs in lowercase, and to accept either case when reading them. The braces style is common in Microsoft tools, where UUIDs are called GUIDs.

What is inside a version 4 UUID

A UUID is a 128-bit number written as 32 hex digits in groups of 8-4-4-4-12. This tool makes version 4 UUIDs, which are random. Only two digits are fixed:

076abaa8-9f35-4d27-af84-178f8b95efdf
              ^    ^
              |    variant: always 8, 9, a or b
              version: always 4

The 4 uses 4 bits and the variant digit uses 2 fixed bits. That leaves 122 random bits. We ran the tool's function 200,000 times. Every result matched this pattern, and 8, 9, a and b each appeared about a quarter of the time.

Where the randomness comes from

Each random digit comes from one byte of your browser's crypto.getRandomValues(). This is the same secure random source that password tools use, not Math.random(). The byte is reduced to a digit from 0 to 15 with a remainder. Because 256 divides evenly by 16, every digit is equally likely. The tool does not call the newer crypto.randomUUID(), but the results are the same kind of UUID.

Can two UUIDs ever be the same?

It is possible, but it is so unlikely that you can ignore it. There are 2¹²² version 4 UUIDs, about 5.3 × 10³⁶. The chance of any repeat among n UUIDs is about:

chance ≈ n² ÷ (2 × 2122)

To reach a 50% chance, you would need to make one billion UUIDs every second for about 86 years. In real systems, repeats come from bugs, not bad luck. For example, someone pastes the same UUID twice, or a program uses a weak random generator. So keep a unique constraint on the database column anyway.

When a UUID is a good choice

• Many machines create records. Phones, servers or offline apps can each make IDs without asking a central database for the next number.
• IDs appear in URLs. An order number like /orders/1043 tells visitors roughly how many orders you have, and invites them to try 1042. A random UUID does not.
• Test data and fixtures, where you need a batch of unique IDs quickly.

Things to watch out for

• Database indexes. Random UUIDs land all over the index instead of at the end. In databases that store rows in primary-key order, such as MySQL with InnoDB, this can slow down inserts on large tables. Store the UUID in a native type, such as uuid in PostgreSQL or BINARY(16) in MySQL. As text it takes 36 bytes instead of 16.
• UUID version 7. RFC 9562 (2024) added version 7. It starts with a timestamp in milliseconds, so new IDs sort in creation order and are kinder to indexes. The trade-off is that anyone can read the creation time from the ID. This tool does not make version 7. Many languages now have a library for it.
• Secret tokens. A version 4 UUID from this tool has 122 secure random bits, which is hard to guess. But RFC 9562 warns not to assume UUIDs are hard to guess, because other generators may be weaker. For password reset links, API keys and session tokens, use a token function made for that purpose.
• Version 1. Older version 1 UUIDs are built from the time and often from the computer's network (MAC) address. They can reveal when and on which machine an ID was made. Version 4 has none of this.