Skip to content
Advertisement

UUID Generator

Generate one or thousands of v4 UUIDs and copy them all at once.

Generator

Settings

5

How UUID Generator works

A UUID is a 128-bit identifier written as 32 hexadecimal digits in five dash-separated groups. Version 4 UUIDs are almost entirely random: 122 bits come from a cryptographically secure random source, with 4 bits fixed to mark the version and 2 bits fixed to mark the variant.

That randomness is what makes them useful. Because no coordination is needed, any number of machines can mint identifiers simultaneously with no registry, no lock, and no round trip to a database — which is why v4 UUIDs are the default for distributed systems, client-generated records, and idempotency keys.

Collision probability is negligible at any realistic scale. With 122 random bits you would need to generate roughly 2.7 × 10^18 UUIDs before reaching a 50% chance of a single collision — about a billion per second for 85 years. The practical risk is not the mathematics but a weak random source; this tool uses the browser’s crypto.getRandomValues, not Math.random.

The version and variant nibbles are visible in the text form: the 13th hex digit is always 4, and the 17th is one of 8, 9, a, or b. Spotting those tells you at a glance whether you are looking at a v4 UUID or something else, such as a time-ordered v1 or v7.

Reference

  • Format: xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx (y ∈ {8, 9, a, b})
  • 128 bits total = 122 random + 4 version + 2 variant
  • Text form: 36 characters. Binary form: 16 bytes.
  • 50% collision chance after ≈ 2.71 × 10^18 identifiers

How to use this generator

  1. Choose how many

    Generate a single identifier, or a batch of hundreds or thousands for seeding test data.

  2. Pick a format

    Standard lowercase hyphenated form suits almost everything; uppercase or unhyphenated variants exist for legacy systems.

  3. Generate

    New values are produced from the browser’s cryptographic random source on every request.

  4. Copy the batch

    Copy one value or the entire list at once, ready to paste into a fixture, a migration, or a test.

Worked examples

Reading the version nibble

Given
f47ac10b-58cc-4372-a567-0e02b2c3d479
Result
Version 4, variant RFC 4122

The 4 opening the third group is the version; the a opening the fourth is the variant. Both are fixed, not random.

An idempotency key

Given
A UUID generated client-side before a payment request
Result
Retries reuse the same key and cannot double-charge

The identifier must be created before the first attempt and reused on every retry, which is exactly what client-side generation makes easy.

Seeding test data

Given
A batch of 5,000 UUIDs
Result
Unique primary keys with no database round trips

Storing them as a native uuid or binary(16) column rather than a 36-character string saves both space and index depth.

When to use it

  • Assigning primary keys client-side so records can be created offline and synced later.
  • Generating idempotency keys so a retried API request cannot be applied twice.
  • Correlating logs and traces across services with a single request identifier.
  • Naming uploaded files so two users cannot overwrite each other.
  • Seeding databases and fixtures with large batches of unique identifiers.

Things to watch out for

  • v4 UUIDs are random, so consecutive values are unordered. As a clustered primary key that causes index fragmentation and poor insert locality — v7, which is time-ordered, was designed for exactly this.
  • They are not secrets. A UUID is unguessable in practice but appears in logs, URLs, and referrer headers; do not use one as a capability token without additional authorisation.
  • Store them as 16 bytes where your database supports it. A 36-character string costs more than twice the space in every index that touches it.
  • Not every 36-character hex string is a valid UUID. Validate the version and variant nibbles if you accept them from clients.

Frequently asked questions

Can two UUIDs ever collide?

In principle yes, in practice no. With 122 random bits you would need about 2.7 quintillion identifiers for a 50% chance of one collision. The realistic risk is a weak random source, which is why this tool uses the browser’s cryptographic generator rather than Math.random.

What is the difference between v4 and v7?

v4 is fully random and therefore unordered. v7 places a Unix timestamp in the high bits, so identifiers sort chronologically — much better as a database primary key because inserts stay at the end of the index instead of scattering across it.

Are UUIDs safe to expose in URLs?

They are unguessable, so exposing one does not leak information the way a sequential integer does. But they are not authorisation: always check that the requesting user is entitled to the resource, rather than treating knowledge of the identifier as permission.

Should I store UUIDs as strings or binary?

Binary — 16 bytes — where your database has a native type. The 36-character text form more than doubles storage and inflates every index that includes the column.

Do I need to worry about case?

UUIDs are case-insensitive on comparison, and RFC 4122 specifies lowercase for output. Some Microsoft tooling emits uppercase, often in braces. Normalise on input so two spellings of the same identifier do not become two rows.

Related Developers tools

All developer tools