UUID Generator — v7, v4 and v1
Generate universally unique identifiers in the browser, one at a time or a hundred at once. v7 is time-ordered and the right default for new database keys.
- 1
b7f2abeb-73c5-4c6b-8a3a-19151868bca1
Encodes the current timestamp plus a random node ID. Values generated within the same millisecond are monotonically incremented. Useful when you need to trace when a record was created.
All significant bits are filled with cryptographically secure random data. The most widely used UUID version — ideal for primary keys, session tokens, and correlation IDs where ordering does not matter.
Embeds a Unix millisecond timestamp in the most-significant bits, making UUIDs sortable by creation time. Dramatically improves database index performance compared to v4. Recommended for new database primary keys.
What a UUID actually contains
A UUID is 128 bits, written as 32 hexadecimal digits in five hyphen-separated groups: 8-4-4-4-12. The hyphens are presentation only — the value is the 16 bytes.
Two of those 128 bits are structural. Four bits in the third group encode the version — the first character of that group is literally the version number, so …-4f68-… is a v4 and …-7734-… is a v7. The two most significant bits of the fourth group encode the variant, which is why the first character there is almost always 8, 9, a or b.
That leaves 122 bits available for the version's own scheme. v4 fills all 122 with random data. v7 spends the first 48 on a Unix millisecond timestamp and randomises the remaining 74. This is the entire difference between them, and it is the difference that matters for databases.
UUIDs were originally specified in RFC 4122. That was obsoleted by RFC 9562 in May 2024, which added versions 6, 7 and 8 — if you are reading older documentation that stops at v5, it predates the current specification.
Every UUID version, and when it applies
Eight versions exist. In practice new systems use two of them, and knowing why the others exist saves you from reaching for the wrong one.
| Version | Built from | Sortable | Use it when |
|---|---|---|---|
| v1 | 60-bit timestamp + clock sequence + MAC address | Poorly — time bytes are stored in the wrong order to sort | You need compatibility with an existing v1 system. Leaks the host MAC address |
| v2 | v1 with a POSIX UID/GID substituted in | No | Effectively never. Defined by DCE Security, unimplemented almost everywhere |
| v3 | MD5 hash of a namespace + name | No | You need the same input to always produce the same UUID and must match an existing v3 system |
| v4 | 122 bits of random data | No | Ordering is irrelevant: session tokens, correlation IDs, opaque external references |
| v5 | SHA-1 hash of a namespace + name | No | Deterministic IDs from stable inputs — preferred over v3 for new work |
| v6 | v1 with the timestamp bits reordered | Yes | You are migrating away from v1 and need to keep its structure. Otherwise use v7 |
| v7 | 48-bit Unix ms timestamp + 74 random bits | Yes, lexicographically | The default for new database primary keys |
| v8 | Entirely implementation-defined | Depends | You need a custom layout and want a version number that says so |
Versions 6, 7 and 8 were introduced by RFC 9562 (2024). Library support is good but not universal — check before relying on v7 in an older runtime.
Why v7 beats v4 as a primary key
This is the single most consequential choice on this page, and the reason is mechanical rather than aesthetic.
Most relational databases store table data in a B-tree ordered by primary key — clustered indexes in SQL Server and MySQL/InnoDB, and the index structure in PostgreSQL. Inserting a row means finding the right leaf page and writing into it.
With v4, every new key is uniformly random, so consecutive inserts land in arbitrary leaf pages spread across the whole index. Three things follow. The pages you need are unlikely to be in memory, so each insert risks a disk read. Pages fill unevenly and split, which fragments the index and wastes space. And the working set for writes is the entire index rather than its tail — on a large table that stops fitting in the buffer pool.
With v7, the leading 48 bits are the current timestamp, so keys generated near each other in time sort near each other. Inserts concentrate at the right-hand edge of the B-tree. That page is already hot in memory, splits are sequential rather than scattered, and the write working set stays small no matter how large the table grows.
The effect is not subtle on large tables — it is the difference between insert throughput staying flat and degrading as the table grows. If you are choosing today and your database or ORM supports v7, there is no case for v4 as a primary key.
The trade-off is that v7 discloses creation time. Anyone holding the ID can read the millisecond it was generated, and two IDs reveal the interval between them. For an internal key that is usually fine — often useful. For an identifier exposed publicly where creation time is sensitive, or where sequential-looking IDs invite enumeration, use v4.
Generating UUIDs in your own code
This tool is for one-off values. In an application, generate them in the database or the standard library:
-- v7 is built in from PostgreSQL 18
CREATE TABLE orders (
id uuid PRIMARY KEY DEFAULT uuidv7(),
ref text NOT NULL
);
-- v4 has been built in since PostgreSQL 13
SELECT gen_random_uuid();// v4 — built into every modern browser and Node 19+
const id = crypto.randomUUID();
// v7 — needs a library, e.g. the uuid package v10+
import { v7 as uuidv7 } from 'uuid';
const key = uuidv7();import uuid
# v4 — standard library, all versions
uuid.uuid4()
# v7 — standard library from Python 3.14
uuid.uuid7()import "github.com/google/uuid"
v4 := uuid.New() // random
v7, _ := uuid.NewV7() // time-ordered-- MySQL has no native uuid type. BINARY(16) is 16 bytes;
-- CHAR(36) is 36 and indexes far worse.
CREATE TABLE orders (
id BINARY(16) PRIMARY KEY,
ref VARCHAR(64) NOT NULL
);
-- Convert on the way in and out
INSERT INTO orders (id, ref) VALUES (UUID_TO_BIN(?), ?);
SELECT BIN_TO_UUID(id) AS id FROM orders;When a UUID is the wrong tool
They are not a universal identifier strategy. Common cases where something else fits better:
- User-facing identifiers —Nobody reads a UUID over the phone or types one from a printed page. For invoice numbers, booking references or support tickets, use a short prefixed code and keep the UUID internal.
- URL slugs —A 36-character identifier in a URL costs you readability and, marginally, click-through. Pair a UUID key with a human slug.
- When you need an ordered counter —Even v7 is only ordered by generation time, not gapless or contiguous. Anything requiring "the 47th record" needs a sequence.
- Very high-volume time-series rows —16 bytes per row plus index overhead adds up over billions of rows. A bigint sequence is 8 bytes and, if you do not need distributed generation, does the job.
- Anything that must be unguessable and revocable —A UUID is unguessable but permanent and carries no expiry or scope. For access, use a real token format that can be rotated and revoked.
About
The UUID Generator produces universally unique identifiers (UUIDs) in version 1 (timestamp-based), version 4 (random), and version 7 (sortable, timestamp-based) formats. UUIDs are used as primary keys in databases, session tokens, file names, and anywhere a guaranteed-unique identifier is needed.
How to use
- 1 Select the UUID version (v1, v4, or v7).
- 2 Choose how many UUIDs to generate (1 to 100).
- 3 Click Generate and copy the results to your clipboard.
- 4 Toggle uppercase or lowercase formatting as needed.
- Which UUID version should I use for database primary keys?
- UUID v7 is the best choice for new database primary keys. Its millisecond-precision timestamp prefix makes UUIDs lexicographically sortable by creation time, which dramatically improves B-tree index performance compared to the random v4. If your database or ORM does not yet support v7, v4 is the widely supported fallback.
- Are UUIDs generated in this tool truly unique?
- UUID v4 uses 122 bits of cryptographically secure random data, making collisions statistically impossible in practice — the probability of a collision in 1 billion UUIDs is less than 1 in a billion. UUID v7 uses 74 random bits plus a timestamp prefix, offering similar collision resistance with sortability.
- Can I generate multiple UUIDs at once?
- Yes. Set the count field to any number between 1 and 100 and click Generate to produce a batch. All UUIDs are displayed in a numbered list and can be copied individually or all at once with the Copy All button.
The full guide
More in Generators & Utilities
See all generators & utilities.