What is a UUID?
A UUID (Universally Unique Identifier) is a 128-bit value used to label information without a central authority to hand out IDs. Written as 32 hexadecimal digits in the familiar 8-4-4-4-12 pattern, a UUID can be generated independently on any machine with a negligible chance of ever colliding with another. That property — globally unique, no coordination required — is why UUIDs are the default identifier for database rows, API resources, event streams, and distributed systems. This tool generates them to RFC 9562, the 2024 standard that supersedes RFC 4122.
UUID v4 vs v7
The practical choice in 2026 is between UUID v4 and UUID v7, and it comes down to one thing: whether the ID should be sortable by creation time. UUID v4 is 122 bits of cryptographically random data — collision-safe and revealing nothing about when it was made. UUID v7 replaces the leading bits with a 48-bit Unix-millisecond timestamp, so IDs generated later sort after earlier ones while keeping the same uniqueness guarantees.
That difference matters most in a database. A v4 primary key lands at a random position in a B-tree on every insert, causing page splits and cache thrashing as the table grows. A v7 primary key inserts in roughly increasing order, so consecutive rows hit the same hot index page — B-tree behavior close to an auto-increment integer, but without a central sequence. PostgreSQL 18 ships a native uuidv7(), and because most ORMs treat UUIDs as opaque 128-bit values, moving from v4 to v7 is usually a one-line change.
When to use which
| Use case | Recommended | Why |
|---|---|---|
| Database primary key | v7 | Time-ordered inserts keep B-tree indexes healthy |
| Session tokens, share links, reset URLs | v4 | Creation time must not leak; pure randomness |
| Event / log correlation IDs | v7 | Natural time sort aids debugging |
| Public-facing opaque IDs | v4 | No ordering information exposed |
| Offline / distributed generation | either | Both need no central coordinator |
How this tool works
Every UUID is generated entirely in your browser and never sent to our
server. The randomness comes from the Web Crypto API
(crypto.randomUUID() for v4, crypto.getRandomValues()
for v7) — never Math.random() — so the values are
cryptographically unique. There are no cookies, no third-party requests, and
no logging. The generated ID exists only on your screen and in your
clipboard.
Frequently asked questions
Is a UUID guaranteed to be unique?
Not mathematically guaranteed, but the collision probability is so small it's treated as unique in practice. You'd need to generate billions of v4 UUIDs before a collision became likely.
What's the difference between a UUID and a GUID?
None, in practice. GUID is Microsoft's name for the same 128-bit standard; the terms are interchangeable.
Should I use v4 or v7?
Use v7 for database primary keys (time-sortable, index-friendly) and v4 for anything where creation order could leak information, like tokens or share links.
Can I use UUID v7 in PostgreSQL?
Yes. PostgreSQL 18 ships a native uuidv7() function; earlier versions can store any UUID this tool generates in a uuid column.
Does this tool store or log my UUIDs?
No. Generation happens in your browser and the value never reaches our server. No cookies, no logging, no third-party requests.
Are these UUIDs cryptographically secure?
The randomness is, yes — it comes from the Web Crypto API. That said, a UUID is an identifier, not a secret; don't use one as a password or an unguessable capability token on its own.
What does "monotonic" mean for UUID v7?
Two v7 UUIDs made in the same millisecond could otherwise sort out of order; this tool uses a per-millisecond counter (RFC 9562 §6.2) so they always sort in the order you generated them.
Can I generate UUIDs offline?
Yes. Once the page has loaded, generation is fully client-side and works with no network connection.