How to Generate UUIDs: v4 vs v7 and When to Use Each

What a UUID is

A UUID (Universally Unique Identifier) is a 128-bit value that can be generated independently on any machine with a negligible chance of colliding with another. That is what makes UUIDs useful: a mobile app, a background worker and a database can all create IDs without asking a central counter for the next number.

UUIDs are written as 32 hexadecimal digits in five groups, 8-4-4-4-12:

f47ac10b-58cc-4372-a567-0e02b2c3d479
              ^    ^
              |    variant (8, 9, a or b for RFC UUIDs)
              version (4)

The first hex digit of the third group is the version, and the first digit of the fourth group encodes the variant — for standard UUIDs it is always 8, 9, a or b. The current specification is RFC 9562, published in May 2024, which replaced RFC 4122 and added versions 6, 7 and 8.

UUID versions at a glance

RFC 9562 also defines two special values: the nil UUID (all zeros) and the max UUID (all f). They are useful as sentinels but should never be used as real identifiers.

v4 vs v7: which should you use?

UUIDv4 is almost entirely random. Of its 128 bits, 6 are fixed by the version and variant, leaving 122 random bits. That is enough that collisions are not a practical concern when the generator uses a cryptographically secure random source: by the birthday bound you would need on the order of 2.7 × 10^18 UUIDs for a 50% chance of a single collision.

UUIDv7 starts with a 48-bit Unix timestamp in milliseconds, followed by the version and variant bits and 74 bits of randomness (some implementations use part of that space as a counter to keep IDs generated in the same millisecond in order). Because the timestamp comes first, v7 UUIDs generated later sort after earlier ones.

That ordering matters for databases. Most primary-key indexes are B-trees. Random v4 keys land at random positions in the index, so inserts touch pages all over it, cause more page splits and keep more of the index hot in memory. Time-ordered v7 keys are appended near the end of the index, much like an auto-increment integer, which gives better index locality and usually better insert performance on large tables.

A practical rule: use v7 for primary keys and event IDs in your own databases, v4 for public identifiers that should reveal nothing, and v5 when you need the same input to always map to the same ID. Note that no UUID version is a secret: do not use UUIDs as passwords or session tokens — use the Password Generator or a dedicated token generator for that.

Generating UUIDs online

1. Open the UUID Generator and choose the version — v4 for random IDs or v7 for time-ordered IDs.
2. Set how many you need. Generating in bulk is useful for seeding test databases or fixtures.
3. Pick a format: lowercase is the canonical form; some systems expect uppercase, braces or no hyphens.
4. Click Generate, then copy or download the list.
5. To read the timestamp inside a v7 UUID, take its first 12 hex digits as a number of milliseconds and paste it into the Timestamp Converter.

Generating UUIDs in code

Browsers and Node.js have a built-in v4 generator backed by a secure random source. For v7, the widely used uuid package provides v7 in recent major versions:

// v4 — built in (browsers in secure contexts, Node.js 19+ as a global)
const id = crypto.randomUUID();

// v7 — npm install uuid
import { v7 as uuidv7, validate, version } from "uuid";
const orderId = uuidv7();

validate(orderId); // true
version(orderId); // 7

import uuid

uuid.uuid4()                                   # random
uuid.uuid5(uuid.NAMESPACE_URL, "https://example.com/")  # deterministic

# Python 3.14+ also includes uuid.uuid7()

-- v4: built in since PostgreSQL 13
CREATE TABLE orders (
  id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  created_at timestamptz NOT NULL DEFAULT now()
);

-- v7: built in from PostgreSQL 18 as uuidv7()

uuidgen                                  # random-based on most systems
uuidgen | tr '[:upper:]' '[:lower:]'     # macOS prints uppercase
python3 -c "import uuid; print(uuid.uuid4())"

Storing and validating UUIDs

• Use a native type where one exists — uuid in PostgreSQL, UNIQUEIDENTIFIER in SQL Server — or BINARY(16) in MySQL. Storing the 36-character string takes more than twice the space and makes indexes larger.
• Compare case-insensitively. RFC 9562 says UUIDs should be output in lowercase but accepted in either case. Normalise to lowercase before comparing strings.
• Validate with a pattern when accepting UUIDs from users. A strict check for a version 1–8 RFC UUID is shown below.
• Do not parse meaning out of v4 IDs. Only the version and variant digits carry information.

const UUID_RE = /^[0-9a-f]{8}-[0-9a-f]{4}-[1-8][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i;

UUID_RE.test("f47ac10b-58cc-4372-a567-0e02b2c3d479"); // true

Other generators for identifiers, hashes and secrets are collected in the security tools category.