Can two UUID v4 values ever collide?

In theory yes, in practice no. With 122 random bits you would need to generate about 2.7 quintillion values before reaching a 50% chance of a single collision, which is far beyond any realistic workload.

Should I use UUID v4 or v7 for a database primary key?

Use v7. It keeps global uniqueness while being time-ordered, so inserts append to the index instead of scattering across it. Keep v4 where the identifier must reveal nothing about creation time.

Are UUIDs generated here random enough to be secure?

They use crypto.randomUUID(), which is required to draw from a cryptographically secure source. That said, unguessability is not authorisation — always check permissions server-side.

Does a UUID contain my MAC address?

Not in version 4. Version 1 embedded a MAC address and timestamp, which is why it fell out of favour; v4 is pure randomness and v7 encodes only a millisecond timestamp.

Security🔒 Browser (client-side)API available📴 Works offlinebeginner

UUID Generator

Generates cryptographically secure, random UUID v4 identifiers (RFC 4122) for database primary keys, session tokens, and unique system entities.

Data stays in your browser

Ready to runInstant execution

All tools →

Result

—

What does this tool do?

Generates cryptographically secure, random UUID v4 identifiers (RFC 4122) for database primary keys, session tokens, and unique system entities.

Why would I use it?

You need unique IDs for database rows, events or API calls.
You want collision-safe identifiers without a central counter.
You are generating test data.

Real-life example

Input

v4, count 3

Output

3f7a9c1e-... 
 6b2d41f0-... 
 8e1c9a22-...

Each UUID is generated with crypto randomness.

Input → Process → Output → Next

Input: Choose version and count.
Process: The browser generates random UUIDs.
Output: One or more UUIDs.
Next action: Use them as identifiers in your data model.

Common mistakes

Using UUIDs as sequential sort keys (use v7 for that).
Assuming UUIDs are unguessable secrets — they are identifiers.
Generating them on a non-crypto source.

What the result means

Random UUIDs are practically unique across systems.

Privacy & security

Your input is processed entirely in your browser and never sent to a YAS server.

API

Endpoint

POST https://yas.sh/api/v1/tools/uuid-generator

Request Header

Content-Type: application/json

cURL

curl -X POST "https://yas.sh/api/v1/tools/uuid-generator" \
  -H "Content-Type: application/json" \
  -d '{"count":2,"version":4}'

JavaScript

const res = await fetch("https://yas.sh/api/v1/tools/uuid-generator", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
  "count": 2,
  "version": 4
}),
});
const data = await res.json();

Python

import requests

r = requests.post("https://yas.sh/api/v1/tools/uuid-generator", json={"count":2,"version":4})
data = r.json()

Field	Type	Required	Description
count	integer	No (default 1)	How many (1–50)
version	integer	No (default 4)	4 (random) or 7 (time-ordered)

Success response

{ "slug": "uuid-generator", "count": 2, "version": 4, "result": ["<uuid>", "<uuid>"] }

Generate 1–50 random UUIDs (v4).

Error responses

400 VALIDATION_ERROR — invalid input or unsupported option.
413 PAYLOAD_TOO_LARGE — input exceeds the 64 KB limit.
429 RATE_LIMIT_EXCEEDED — rate limit exceeded (60 req/min).

Limits

Maximum input: 64 KB per request.
Rate limit: 60 requests/min per IP address.
Authenticated accounts benefit from higher tier quotas.

How UUID Generator works

A version 4 UUID is 128 bits of which 122 are random; the remaining six are fixed by RFC 9562 (which superseded RFC 4122 in 2024). The 13th hex digit is always '4' to mark the version, and the 17th is one of 8, 9, a or b to mark the variant. The random bits come from crypto.randomUUID() or crypto.getRandomValues(), both backed by the platform CSPRNG.

Collision probability follows the birthday bound. With 122 random bits you would need on the order of 2.7 × 10^18 UUIDs before a 50% chance of any collision, and about a billion UUIDs before the probability reaches roughly 10^-9. For application identifiers this is comfortably below the failure rate of the hardware the database runs on.

The canonical text form is 36 characters: 32 hex digits in 8-4-4-4-12 groups separated by hyphens. Case is insignificant for comparison (RFC 9562 mandates lowercase on output, accepts either on input), and the binary form is 16 bytes, which is what you should store when the database offers a native UUID or BINARY(16) column.

When to use it: real-world scenarios

Generating a primary key on the client before saving

The client can create the ID, render the optimistic UI and send the record with its identity already fixed. That removes a server round trip from the critical path and makes retries idempotent, because a duplicate submit carries the same key.

Correlating a request across services

Attach a UUID as a correlation or trace ID at the edge and propagate it through every log line and downstream call. When something fails at 03:00, one grep across services reconstructs the full path.

Naming uploaded objects in blob storage

Using a UUID as the object key avoids collisions between users who upload invoice.pdf on the same day, and avoids leaking the original filename or a guessable sequence in the URL.

Creating idempotency keys for payment APIs

Stripe-style idempotency requires a unique key per logical operation, reused verbatim on retry. A v4 UUID generated once and stored with the pending request is the standard implementation.

Pro tips

Prefer UUID v7 for database primary keys. Its leading 48-bit millisecond timestamp makes new rows sort at the end of the B-tree index, avoiding the write amplification and page splits that random v4 keys cause on large tables.
Store UUIDs as 16 bytes, not as a 36-character string. The text form costs more than twice the space and slows every index comparison.
Never treat a UUID as a secret or a capability token by itself. It is unguessable but it is also frequently logged, put in URLs and shared in support tickets.
Do not parse meaning out of a v4 UUID. There is no timestamp, no MAC address and no sequence — only the version and variant nibbles are structural.

Limitations and edge cases

What this tool deliberately does not do, and where it will disagree with other implementations.

Version 4 UUIDs are unordered, so using them as a clustered primary key degrades insert performance on large tables.
The 36-character text form is unfriendly in URLs and unusable in a phone conversation. Use NanoID or ULID where the identifier is user-facing.
Uniqueness relies on the quality of the platform CSPRNG. In an environment with a poorly seeded entropy pool — some embedded devices and freshly cloned VM images — the guarantee weakens.
A UUID carries no authorisation. Exposing one in an API path still requires a permission check on every request.

Frequently asked questions

Can two UUID v4 values ever collide?: In theory yes, in practice no. With 122 random bits you would need to generate about 2.7 quintillion values before reaching a 50% chance of a single collision, which is far beyond any realistic workload.
Should I use UUID v4 or v7 for a database primary key?: Use v7. It keeps global uniqueness while being time-ordered, so inserts append to the index instead of scattering across it. Keep v4 where the identifier must reveal nothing about creation time.
Are UUIDs generated here random enough to be secure?: They use crypto.randomUUID(), which is required to draw from a cryptographically secure source. That said, unguessability is not authorisation — always check permissions server-side.
Does a UUID contain my MAC address?: Not in version 4. Version 1 embedded a MAC address and timestamp, which is why it fell out of favour; v4 is pure randomness and v7 encodes only a millisecond timestamp.

Related tools

UUID v7 Generator Random String