Free SEO, DNS & Email Tools — Web Tool Bench

UUID Generator — version 4 identifiers

Generate random UUIDs, with a note on what they cost as database keys.

Free · no sign-up Updated 4 Aug 2026 72 visits
Enter details Be the first to review Live
Verify you are humanThis quick check keeps automated scripts from overloading the tool. Your answer is sent to Google for verification and nothing else is recorded.

Free and instant — results appear in seconds. No sign-up, no limits, and nothing you type is stored.

Version 4 UUIDs are 122 random bits formatted as 36 characters. Their value is that any system can generate one independently without coordination and collisions remain effectively impossible.

That independence is the entire point — and the reason they are worth their costs in distributed systems and worth reconsidering in a single database.

The index fragmentation problem

8f14e45f-ceea-467a-9c8e-3ba2a4c7d5b1
3d94f2a1-7b8c-4e2d-a1f6-9c4e8b2d7a35
c7a91e4b-2f6d-4a89-b3e1-5d8f7c2a9e46

As primary keys in MySQL with InnoDB, these cause a specific and often-unnoticed performance problem.

InnoDB stores rows physically ordered by primary key. Sequential integer IDs append at the end — cheap, and the working set stays small. Random UUIDs insert at random positions throughout the index, forcing page splits and scattering writes across the whole B-tree. On a large table, insert throughput can drop several-fold and the index no longer fits comfortably in memory.

Storing them as CHAR(36) compounds it: 36 bytes instead of 16, and every secondary index carries a copy of the primary key.

The fixes, in order of preference:

1. BINARY(16) rather than CHAR(36). Immediate 55% reduction in key size.
2. UUIDv7, which is time-ordered. Keeps global uniqueness while inserting sequentially, removing the fragmentation entirely.
3. Integer primary key internally, UUID as a separate indexed column for external exposure. Best of both, at the cost of a second index.

When a UUID is the right choice

  • IDs generated by clients or offline devices before reaching the server
  • Merging records across databases without collision
  • Public identifiers that should not reveal record counts or allow enumeration
  • Distributed systems with no central sequence

That last point is a genuine security consideration. Sequential IDs in URLs let anyone enumerate your records and estimate your volume from an invoice number.

Versions

  • v1 — timestamp and MAC address. Ordered, but leaks the host address and creation time.
  • v4 — random. The general-purpose default.
  • v7 — timestamp-ordered with random bits. Designed to fix the database index problem while keeping v4's properties.

Use v4 unless you are storing many of them in an ordered index, in which case v7 is worth adopting.

Collision probability

With 122 random bits, you would need to generate around one billion UUIDs per second for roughly 85 years to reach a 50% chance of a single collision. It is not a practical concern, provided the random source is genuinely cryptographic — which is the one thing worth checking in any implementation.

Frequently asked questions

Are UUID collisions possible?

Theoretically, but not practically. With 122 random bits you would need to generate about a billion per second for 85 years to reach even odds of one collision. The real risk is a weak random source, not the mathematics.

Should I use UUIDs as database primary keys?

Be careful with random v4 UUIDs in InnoDB, where rows are stored physically ordered by primary key — random values cause page splits and scatter writes across the index. Store as BINARY(16) rather than CHAR(36), or use time-ordered UUIDv7, or keep an integer key internally and expose a UUID separately.

What is the difference between UUID v1, v4 and v7?

Version 1 encodes a timestamp and MAC address, which makes it ordered but leaks host information. Version 4 is fully random and is the general-purpose default. Version 7 is time-ordered with random bits, designed to keep v4's properties while inserting sequentially in a database index.

Why use UUIDs instead of sequential IDs?

They can be generated independently without coordination, which matters for offline clients and distributed systems. They also avoid exposing record counts — a sequential invoice number in a URL tells anyone how many invoices you have issued and invites enumeration.

Reviews

No reviews yet. If this tool solved something for you, yours would be the first — and it helps other people decide whether it is worth their time.

Write a review
Your rating
Select a rating
Verify you are humanThis quick check keeps automated scripts from overloading the tool. Your answer is sent to Google for verification and nothing else is recorded.