Generate UUIDs online: single or bulk (v4)

You need a unique identifier for a record, a request, a test fixture, or a config value, and you need it now. A UUID is the standard answer: a 128 bit identifier you can generate anywhere without coordinating with anyone. The UUID & Token Generator produces version 4 UUIDs one at a time or in bulk, plus secure random tokens with custom length and character sets, all in your browser. Nothing you generate leaves the page.

What a UUID actually is

UUID stands for universally unique identifier. GUID, globally unique identifier, is Microsoft's name for the same thing; the two terms are interchangeable in practice, and a GUID from a .NET codebase and a UUID from a Postgres column follow the same specification.

A UUID is 128 bits, conventionally written as 32 hexadecimal digits in an 8-4-4-4-12 grouping:

f47ac10b-58cc-4372-a567-0e02b2c3d479

Five groups, 36 characters including the dashes. Uppercase and lowercase hex are both valid, though lowercase is the common convention.

Where the 4 comes from in version 4

There are several UUID versions, and the version number is baked into the value itself. Version 4 is the random one: nearly all of its 128 bits come from a cryptographically secure random source, with two small fields fixed by the spec.

Look at the example again:

f47ac10b-58cc-4372-a567-0e02b2c3d479
              ^    ^

The first character of the third group is the version nibble. In a v4 UUID it is always 4. The first character of the fourth group is the variant field, and in standard UUIDs it is always one of 8, 9, a, or b. Those two positions are why every v4 UUID you generate has a 4 in the same spot, and why a value with a 7 there is a different version entirely. The remaining 122 bits are random.

Should you worry about collisions?

Not in any practical sense. With 122 random bits, the space of possible v4 UUIDs is so large that you would need to generate an astronomically large number of them, far beyond what any real system produces, before a duplicate becomes a realistic possibility. Every mainstream database, distributed system, and cloud platform treats v4 UUIDs as unique without checking. If your generator uses a proper cryptographic random source, which the browser's crypto API is, collision risk is not a factor in your design.

One UUID or five hundred

Generating a single UUID is the common case: you need an ID for a config entry, a correlation ID to trace a request, or a placeholder while writing a test. Paste, copy, done.

Bulk generation matters when you are seeding a database, building fixture data, or preparing a batch import. Rather than clicking generate two hundred times, set the count in the UUID & Token Generator and copy the whole list at once, or copy individual values as you need them.

The same tool also generates secure random tokens with a chosen length and character set. That is the right shape for API keys, webhook secrets, and temporary passwords, where you want dense randomness rather than the fixed UUID format.

When v4 is the wrong choice

Random UUIDs are ideal when you only need uniqueness. They are less ideal as database primary keys at scale: because consecutive inserts land at random positions in the index, they fragment it and hurt write performance. Newer time ordered versions, v7 in particular, keep the uniqueness while sorting roughly by creation time, which indexes much better. If you are choosing a key format for a table, UUID v4 vs v7 as database keys walks through the tradeoff. This tool generates v4; for one off identifiers, fixtures, and correlation IDs, v4 remains exactly right.

One last note: a UUID is an identifier, not a secret. It is hard to guess, but it is not authentication. Never treat "you would have to know the UUID" as an access control; if something needs protecting, protect it with real authorization, and use a proper random token where a secret is actually required.