Are these UUIDs sent anywhere?

No. They're generated entirely in your browser using the Web Crypto API; nothing is transmitted to a server.

Version 4 UUIDs are generated from random bits (rather than a timestamp or hardware address), as defined in RFC 9562 (which superseded RFC 4122) — 122 of the 128 bits are random, making collisions astronomically unlikely.

Is this random number generator good enough for security use?

Yes for the UUIDs themselves — they use crypto.getRandomValues, a cryptographically secure source, not Math.random(). That said, a UUID is an identifier, not a secret; don't rely on one being unguessable the way you would a password.

Can two calls ever produce the same UUID?

In theory, but the probability is negligible: with 122 random bits, you'd need to generate roughly a billion UUIDs per second for about 85 years before a 50% chance of any collision.

UUID Generator

Generate one or up to 100 random version 4 UUIDs (RFC 9562, formerly RFC 4122) using your browser's cryptographic random number generator. Nothing leaves your browser.

Loading tool…

Worked examples

A single UUID
The everyday case: one random, unique identifier for a new database row, object key or session token.
A batch of 5 for test fixtures
Generating several IDs at once to seed sample data or mock records without collisions.
The maximum batch of 100
The largest single batch this tool produces at once — useful for quickly seeding a bigger dataset.

What this tool does

A UUID (Universally Unique Identifier) is a 128-bit value, conventionally written as 32 hex digits split into five groups like f47ac10b-58cc-4372-a567-0e02b2c3d479, designed so that generating one independently on any machine is extremely unlikely to collide with any other UUID ever generated. This tool generates one or up to 100 random version 4 UUIDs at once, using your browser's cryptographically secure random number generator — never a server, and never Math.random().

When you need it

Assigning a unique primary key or identifier to a new database row, object, or resource without coordinating with a central counter or authority.
Generating a session token, request ID, or idempotency key that needs to be unique but doesn't need to be memorable or short.
Creating sample or fixture data for tests, seeding a database, or mocking API responses that reference IDs.
Producing a batch of IDs up front to assign to resources as they're created later in a pipeline or migration script.

Why version 4, and what "random" means here

UUIDs come in several versions defined by RFC 9562 (published in 2024, superseding the original RFC 4122), differing in how their bits are derived — version 1 from a timestamp and MAC address, version 7 from a Unix timestamp plus random bits so IDs sort by creation time, version 4 purely from randomness. Version 4 is the random variant: of its 128 bits, 122 are randomly generated and the remaining 6 are fixed — 4 bits holding the version number 4 and 2 bits (10) marking the standard variant — which is why every ID this tool produces starts differently but always follows the same 8-4-4-4-12 hex-digit pattern with a 4 in a fixed position.

The randomness comes from crypto.getRandomValues, the Web Crypto API's cryptographically secure random source — the same category of randomness used for generating encryption keys — rather than Math.random(), which is not designed to be unpredictable and isn't suitable for anything where collision resistance actually matters.

How unlikely is a collision, really

With 122 random bits, the space of possible version 4 UUIDs is astronomically large — about 5.3 × 10^36 possible values. The commonly cited estimate is that you'd need to generate roughly a billion UUIDs every second for about 85 years before the probability of any two colliding reaches 50%. For essentially any practical application — database keys, session IDs, distributed system identifiers — this makes collisions a non-issue, though it's worth remembering a UUID is an identifier meant to be unique, not a secret meant to be unguessable; don't use one as a substitute for a real access token or password.

Working with a batch

Generating more than one at a time produces each UUID independently and randomly — there's no relationship between consecutive UUIDs in a batch, so they can be assigned in any order to the resources that need them. The output is one UUID per line, ready to paste into a spreadsheet, a SQL INSERT statement, or a test fixture file.

Limits

Each generation produces between 1 and 100 UUIDs. Because generation is genuinely random, results are never reproducible between runs, so the worked examples on this page show the shape of the output rather than a fixed value — every UUID has 4 as the first digit of its third group and 8, 9, a or b as the first digit of its fourth.

Frequently asked questions

Are these UUIDs sent anywhere?: No. They're generated entirely in your browser using the Web Crypto API; nothing is transmitted to a server.
What does 'v4' mean?: Version 4 UUIDs are generated from random bits (rather than a timestamp or hardware address), as defined in RFC 9562 (which superseded RFC 4122) — 122 of the 128 bits are random, making collisions astronomically unlikely.
Is this random number generator good enough for security use?: Yes for the UUIDs themselves — they use crypto.getRandomValues, a cryptographically secure source, not Math.random(). That said, a UUID is an identifier, not a secret; don't rely on one being unguessable the way you would a password.
Can two calls ever produce the same UUID?: In theory, but the probability is negligible: with 122 random bits, you'd need to generate roughly a billion UUIDs per second for about 85 years before a 50% chance of any collision.