UUID Generator

Cryptographically random v4 UUIDs, generated in your browser.

How to generate UUIDs

  1. Set how many you want, from 1 up to 1000. The page starts with a batch of five already generated.
  2. Tick UPPERCASE if your codebase or style guide wants capital hex, or No hyphens if you need the bare 32-character form.
  3. Click Generate, then Copy all. Each UUID sits on its own line, so pasting into a spreadsheet, seed file, or SQL insert works cleanly.

Changing either checkbox regenerates the batch immediately, so flip the format first if you care about keeping a specific set of values.

A worked example

Say you are seeding a test database and need 200 primary keys. Type 200 in the count field, leave both checkboxes off, and click Generate. You get 200 lines like 3b2f1c9e-8d4a-4f6b-9a1e-7c5d2e8f0a3b, each one 36 characters with the version digit 4 always in the third group and the variant character (8, 9, a, or b) leading the fourth. Tick No hyphens and the same generation produces 32-character strings, which is handy for systems that store UUIDs as raw hex. Ask for more than 1000 and the tool quietly caps you at 1000; ask for zero or garbage and it generates one.

Where the randomness comes from

These are version 4 UUIDs as defined by RFC 4122: 122 bits of randomness plus 6 fixed bits that mark the version and variant. The tool uses crypto.randomUUID, the generator built into modern browsers, which draws from the operating system's cryptographic entropy source. On older browsers without that function, the code falls back to filling 16 bytes from crypto.getRandomValues and setting the version and variant bits by hand, which produces byte-identical results. Neither path involves Math.random, and nothing is sent to a server. One practical note from using UUIDs in real schemas: store them lowercase and hyphenated unless you have a concrete reason not to, because that is the canonical text form and the one every debugging tool expects to see.

Honest limitations

This tool only makes version 4. If you need v1 (timestamp based), v5 (name based, hashed), or the newer sortable v7, you will need a different generator, and for database indexes at serious scale v7 is genuinely worth a look because random v4 keys fragment B-tree indexes. The batch limit is 1000 per click, which is a UI decision rather than a technical one; click twice for 2000. And while collisions are possible in theory, at 122 random bits you would need to generate billions of UUIDs per second for decades before a duplicate became likely, so uniqueness checking is not something the tool does or needs to do.

Frequently asked questions

What is a v4 UUID?

A version 4 UUID is a 128-bit identifier generated from random data, formatted as 32 hex digits like 550e8400-e29b-41d4-a716-446655440000. The "4" in the third group marks the version.

Can two v4 UUIDs collide?

Theoretically yes, practically no. With 122 random bits, you would need to generate about 2.7 quintillion UUIDs to reach even a 50% chance of a single collision.

Are these safe for database keys and API IDs?

Yes — that is their most common use. They are generated with crypto.getRandomValues, the browser's cryptographic RNG, and never leave your device.