Can two generated UUIDs ever collide?

Theoretically yes, practically no: with 122 random bits you would need ~2.7×10^18 UUIDs for a 50% chance of one collision. Real-world duplicates come from broken RNG setups (identically seeded clones), not from probability.

Which UUID version should I use?

v4 for general use — random, simple, universally supported. v7 for new database primary keys (time-ordered, index-friendly). v5 when the same input must always map to the same ID. v1 mostly appears in legacy systems.

Are UUIDs safe to expose in URLs?

Yes in the sense that v4 IDs are not enumerable (unlike sequential integers, they resist scraping by incrementing). But treat that as obscurity, not authorization — always enforce access control server-side.

Why did my database get slow with UUID primary keys?

Random v4 keys scatter inserts across the clustered index, causing page splits and cache misses on write-heavy tables (worst on MySQL/InnoDB). Use v7/ULID for new hot tables, keep the key out of the clustered index, or accept it at moderate volume — and store as 16-byte uuid, not text.

Uppercase or lowercase?

RFC 4122/9562 specify lowercase output while requiring parsers to accept both. Emit lowercase, compare case-insensitively (or normalize on ingest), and let a native uuid column handle it where possible.

Is the generation secure?

Yes — values come from the browser's CSPRNG (crypto.getRandomValues), the same entropy source used for cryptographic keys, and never leave your machine.

UUID Generator | Random & UUID

About UUID Generator

A UUID (universally unique identifier, RFC 4122 — updated by RFC 9562 in 2024) is a 128-bit value written as 36 characters: 8-4-4-4-12 hex digits, like 3f2b8c1e-9d4a-4f6b-8a2e-5c7d9e0f1a2b. Its point is coordination-free uniqueness: any machine can mint IDs at any time with no central authority, no database round-trip, and no realistic risk of collision.

This generator produces version 4 (random) UUIDs using the browser's cryptographically secure RNG. v4 is the default choice across the industry: 122 of the 128 bits are random (6 bits are fixed by the version and variant fields), giving 2^122 ≈ 5.3×10^36 possible values.

How to use UUID Generator

Choose how many UUIDs you need.
Click Generate to create UUID v4 values.
Copy one or all generated UUIDs.

Example

Input

Your input or data here

Output

Result will appear here after running the tool

How likely is a collision, really?

Birthday-paradox math: to reach even a 50% chance of one collision among v4 UUIDs, you would need about 2.7×10^18 of them — a billion UUIDs per second for 86 years. At any practical scale (billions of rows), the probability is far below the chance of a cosmic-ray bit flip corrupting your data instead. Collisions you meet in practice come from broken generation — seeding a non-crypto RNG identically in cloned VMs or containers — not from the math.

UUID versions: which one do you want?

The version nibble (first character of the third group) tells you how a UUID was made:

v4 — random. The general-purpose default; what this tool generates.
v7 (RFC 9562, 2024) — Unix-timestamp-prefixed + random. Sorts by creation time; the new best practice for database primary keys.
v1 — timestamp + MAC address. Sortable-ish, but historically leaked the generating machine's MAC (famously used to track the author of the 1999 Melissa virus).
v5/v3 — deterministic, hashed from a namespace + name (SHA-1/MD5). Same input always yields the same UUID — for stable IDs derived from external keys.
Nil (all zeros) and Max (all f) — special sentinel values.

UUIDs as database keys — the fragmentation issue

Purely random v4 keys write to random positions in a B-tree index. On insert-heavy tables (especially MySQL/InnoDB, where the primary key is the clustered index), that causes page splits, cache-unfriendly access, and index bloat. This is the problem v7 was standardized to fix: its leading 48 bits are a millisecond timestamp, so new keys land near each other while remaining unique and unguessable enough for most uses.

Practical guidance: v4 is perfectly fine for moderate write volume, for non-clustered key columns, and for Postgres (heap tables suffer less). Choose v7 (or ULID) when designing new high-ingest tables. Storage-wise, use the native uuid type (16 bytes) rather than a 36-char string (Postgres: uuid; MySQL 8: BIN_TO_UUID/UUID_TO_BIN).

Common errors and how to fix them

Duplicate UUIDs across servers or containers

Cause: Generation with a non-cryptographic RNG seeded identically (cloned VM images, forked processes sharing RNG state).

Fix: Use CSPRNG-based generation (crypto.randomUUID(), uuid library v4, database gen_random_uuid()). Never seed UUID generation manually.

"Invalid UUID" from a validator or database

Cause: Wrong format: missing hyphens, wrong group lengths, a v4 with an impossible variant nibble, or Microsoft-style braces {…}.

Fix: Normalize to lowercase 8-4-4-4-12 without braces. The UUID Validator tool pinpoints which part is malformed.

Sorting by UUID returns rows in nonsense order

Cause: v4 is random by design — it carries no creation-time information.

Fix: Sort by a created_at column, or migrate new tables to v7 keys, which sort chronologically by construction.

Same-looking UUIDs compare as different

Cause: Case mismatch (RFC output is lowercase; some systems emit uppercase) or an invisible whitespace character from copy/paste.

Fix: Normalize case and trim before comparing; store in a native uuid column so the database normalizes for you.

Tips and best practices

In modern runtimes you rarely need a library: crypto.randomUUID() (browsers, Node 16.7+), Python uuid.uuid4(), Postgres gen_random_uuid().
UUIDs are identifiers, not secrets: v4 is unguessable in practice, but never rely on 'unguessable URL' as your only access control.
Prefer 16-byte native storage over 36-char text — smaller indexes, faster joins.
Deriving stable IDs from external data (email → same UUID everywhere)? That's v5 with a namespace, not v4.
For log correlation, generate one request ID at the edge and propagate it — a fresh UUID per service defeats the purpose.

Frequently asked questions

Can two generated UUIDs ever collide?: Theoretically yes, practically no: with 122 random bits you would need ~2.7×10^18 UUIDs for a 50% chance of one collision. Real-world duplicates come from broken RNG setups (identically seeded clones), not from probability.
Which UUID version should I use?: v4 for general use — random, simple, universally supported. v7 for new database primary keys (time-ordered, index-friendly). v5 when the same input must always map to the same ID. v1 mostly appears in legacy systems.
Are UUIDs safe to expose in URLs?: Yes in the sense that v4 IDs are not enumerable (unlike sequential integers, they resist scraping by incrementing). But treat that as obscurity, not authorization — always enforce access control server-side.
Why did my database get slow with UUID primary keys?: Random v4 keys scatter inserts across the clustered index, causing page splits and cache misses on write-heavy tables (worst on MySQL/InnoDB). Use v7/ULID for new hot tables, keep the key out of the clustered index, or accept it at moderate volume — and store as 16-byte uuid, not text.
Uppercase or lowercase?: RFC 4122/9562 specify lowercase output while requiring parsers to accept both. Emit lowercase, compare case-insensitively (or normalize on ingest), and let a native uuid column handle it where possible.
Is the generation secure?: Yes — values come from the browser's CSPRNG (crypto.getRandomValues), the same entropy source used for cryptographic keys, and never leave your machine.

Embed this tool

Add UUID Generator to your own site, blog post, or internal docs — free, no signup. The widget runs entirely in your visitors' browsers, same as it does here.