UUID Explained — v4 vs v7 (and v1)

A UUID (Universally Unique Identifier) is a 128-bit label meant to identify something uniquely without a central authority handing out numbers. If you’ve ever needed a unique row ID, a filename that can’t collide, or a key for a distributed system, you’ve met UUIDs. The UUID Generator creates v4, v1, and v7 locally using Web Crypto — nothing is sent to a server.

TL;DR

A UUID is a 128-bit identifier; the version you pick changes what those bits mean.

• v4 is fully random (the default) — the standard choice when you just need a unique ID.
• v7 is time-sortable — it embeds a Unix-millisecond timestamp, so it sorts chronologically and makes a far better database index key.
• Generated locally with Web Crypto — crypto.getRandomValues does the randomness in your browser, so no server is involved and no value ever leaves the device.

What a UUID is

A UUID is 128 bits of data, conventionally rendered as 32 hex digits in five groups separated by hyphens — the 8-4-4-4-12 layout:

550e8400-e29b-41d4-a716-446655440000

A few bits are reserved to mark the version (the 4 in the third group above means v4) and the variant (the leading a/b/8/9 in the fourth group). Everything else carries the actual identifying data, and what that data is depends on the version. The total space — 2¹²⁸ possible values — is so vast that random UUIDs effectively never collide at any realistic scale.

One thing a UUID is not: a secret. It’s an identifier, like a license-plate number. Knowing one doesn’t let you derive another, but a UUID on its own provides no access control — don’t use it as a password or a token.

UUID v4 — the random default

v4 is the version most people mean when they say “UUID.” Of its 128 bits, 122 are random (6 are fixed for version and variant), drawn from a cryptographic random source. The result is an identifier with no relationship to time, place, or any other value.

Because the random space is so large, the chance of two independently generated v4 UUIDs colliding is astronomically small — you would need to generate billions per second for years before it became plausible. That makes v4 the right choice whenever you need a unique ID and you don’t care about ordering: a request ID, a session key, a filename. The trade-off is that v4 values are scattered uniformly across the space, which is bad news for a database index (more on that below).

UUID v7 — the time-sortable one

v7 embeds a Unix-millisecond timestamp in its leading bits, with the remaining bits random. The defining consequence: v7 UUIDs sort in the order they were created.

That matters for databases. A primary-key index works best when inserts are sequential, because new rows land next to each other in the index (an “append” pattern) instead of scattered randomly across pages. v4 inserts hit random pages — causing random disk I/O, page splits, and index fragmentation as the table grows. v7 inserts cluster together, so the database writes sequentially and the index stays compact.

For any table that grows over time — orders, events, log rows — v7 is usually the better primary key. You still get uniqueness across machines without coordination, but with the index behaving itself.

UUID v1 — the legacy one

v1 also encodes a timestamp (60 bits of a 100-nanosecond clock since 1582) plus a node identifier, historically derived from the machine’s MAC address. It is sortable in the same sense as v7, but it has two drawbacks that make it rarely the right choice now:

• Privacy leak — embedding the MAC address in every UUID reveals the generating machine’s network hardware and makes UUIDs from one node trivially linkable. In a world of privacy by default, that’s a real cost.
• No real advantage over v7 — v7 gives you time ordering with a clean Unix-ms timestamp and no hardware fingerprint, so the reasons to reach for v1 have largely vanished.

If you have existing v1 data, it still works fine; just don’t start new systems on v1. v4 (when order doesn’t matter) or v7 (when it does) covers essentially every modern need.

Step-by-step: generate UUIDs

The UUID Generator runs entirely in your browser using Web Crypto, so the random bytes are produced locally and nothing is uploaded. Here is the workflow:

1. Pick the version. The v4 / v1 / v7 buttons select which UUID version to generate (v4 is selected by default).
2. Choose the Count. The Count select picks how many to generate: 5, 10, 25, 50, or 100 (max 100). The default is 10.
3. Pick a format. Seven output formats shape the result:
   • plain — the standard 8-4-4-4-12 form, like 550e8400-e29b-41d4-a716-446655440000.
   • UPPER — all uppercase, for systems that prefer it.
   • no hyphens — the 32 hex digits concatenated, like 550e8400e29b41d4a716446655440000.
   • {braces} — wrapped in {...}, the Microsoft GUID style.
   • “string” — wrapped in double quotes, ready to paste into a JSON value.
   • SQL IN — formatted as ('...','...') for a SQL IN (...) clause.
   • JS array — formatted as ["...","..."], a drop-in JavaScript array literal.
4. Generate. Click New for a single UUID, or Generate to produce the full Count at once (bulk generate).
5. Copy. Click Copy to copy all the generated values to your clipboard.

Switching the version immediately generates a fresh single value in that version, so you can compare formats side by side.

FAQ

Are UUIDs secret?

No. A UUID is an identifier, not a secret. Knowing one UUID doesn’t let you predict another, and a v4/v7 value on its own grants no access. If you need something that should be hard to guess — a password, an API token, a session secret — generate a real secret with the Password & Token Generator instead. UUIDs are for uniqueness, not for access control.

v4 or v7 for my database?

For a table that grows over time, v7 is usually the better primary key: it sorts by creation time, so inserts are sequential and the index stays compact instead of fragmenting under random I/O. Use v4 when order doesn’t matter and you want the broadest compatibility — request IDs, cache keys, or anywhere the value is just a label. If you’re unsure, pick v7 for new primary keys and v4 for everything else.

What format should I pick?

It depends where the value is going. plain is the safe default and what most systems expect. UPPER suits systems that store GUIDs in uppercase. no hyphens saves 4 bytes and fits tight formats. {braces} matches the Microsoft GUID convention. “string” drops straight into a JSON value, SQL IN into a database query, and JS array into JavaScript source. Pick the shape that matches your destination.

Can I generate many at once?

Yes. Set the Count (up to 100) and click Generate to produce that many UUIDs at once, then Copy to grab them all. If you only need one, New produces a single value without touching the count.