UUID v4 vs v1: Which UUID Version Should You Use?

By Narender Chaudhary, Editorial & Product Lead · 30 June 2026 · 5 min read

A UUID is a 128-bit identifier you can generate anywhere without a central authority and trust to be unique. But there's more than one kind. The two you'll meet most are version 1 and version 4, and they're built in completely different ways. Here's how they differ and which to reach for.

What a UUID looks like

Every UUID is 32 hexadecimal digits in the familiar 8-4-4-4-12 pattern, like f47ac10b-58cc-4372-a567-0e02b2c3d479. One digit identifies the version. The format is identical across versions — what changes is how the bits are filled in.

UUID v1 — time and MAC based

Version 1 combines the current timestamp with the computer's MAC address and a counter. Because it embeds time, v1 IDs are roughly sortable by creation order, which can help database indexing. The downside: a v1 UUID can leak when and on which machine it was created, a privacy and security concern if the IDs are exposed publicly.

UUID v4 — fully random

Version 4 fills the identifier with 122 random bits. It carries no timestamp and no hardware information, so it leaks nothing and is unpredictable. The collision risk is negligible — you'd need to generate billions before a clash became likely. This is why v4 is the default in most languages and the version the UUID generator produces.

Which one should you use?

For almost everything, choose v4: it's simple, private and unpredictable. Consider v1 (or the newer time-ordered v7) only when you specifically need IDs that sort by creation time for database performance — and even then, weigh the metadata leak. If you need a one-way fingerprint instead of an identifier, use the hash generator; to decode a timestamp embedded in data, try the timestamp converter. More on the developer tools page.

Frequently asked questions

Is UUID v4 safe to use as a database primary key?

Yes — v4 UUIDs are widely used as primary keys because they can be generated anywhere without coordination. Just add an index; fully random keys can fragment indexes more than sequential ones.

Why would anyone use v1 over v4?

Because v1 embeds a timestamp, the IDs roughly sort by creation order, which can improve index locality. Many teams now use UUID v7 for that instead, since it's time-ordered without exposing a MAC address.

Can two v4 UUIDs ever collide?

In theory yes, but with 122 random bits you'd need to generate billions of them before a single collision became likely, so they're treated as practically unique.