UUID Generator

A UUID is a 128-bit identifier designed to be unique without any central coordination. That is the whole value proposition: two systems, in two data centres, with no communication between them, can each mint identifiers and be confident they will never clash.

The anatomy

A UUID renders as 32 hexadecimal digits in five groups: 8-4-4-4-12.

f47ac10b-58cc-4372-a567-0e02b2c3d479
              ↑    ↑
           version variant

The first digit of the third group is the version. The first digit of the fourth group is the variant, which for all modern UUIDs is 8, 9, a or b — indicating the RFC 4122 layout.

Versions worth knowing

v1 — timestamp and node. Combines a 60-bit timestamp with the generating machine's MAC address. Ordered and traceable, but it leaks the creation time and, historically, hardware identity. Still used in legacy COM and Windows systems.

v3 and v5 — name-based hashes. Deterministic: the same namespace plus the same name always yields the same UUID. v3 uses MD5, v5 uses SHA-1; prefer v5. Useful for generating stable identifiers from URLs, email addresses or domain names.

v4 — random. 122 random bits. The default choice, supported natively by crypto.randomUUID() in every modern browser.

v6 — reordered v1. The same fields as v1 but arranged so the timestamp sorts first. A compatibility option for systems migrating off v1.

v7 — Unix time plus random. A 48-bit millisecond timestamp followed by 74 random bits. Sortable, index-friendly and privacy-safe, because the timestamp carries no hardware identity. This is the version new systems should choose for primary keys.

NIL. 00000000-0000-0000-0000-000000000000 — the sentinel value meaning "no identifier". Useful as a default and for testing null handling.

Choosing between v4 and v7

Use v4 when identifiers are exposed to users or clients and you do not want them to reveal anything about creation order or rate. An API key, a session ID, a file name in a public bucket — all better as v4, because v7 lets an observer infer when things were created and how fast.

Use v7 for internal database primary keys. The sequential prefix turns random-insert index churn into append-only writes. On a large PostgreSQL or MySQL table the difference in index size and write latency is substantial and well documented.

Formatting for real use

• Plain hex (32 characters) for fixed-width storage and some legacy systems.
• Braces for .NET, SQL Server's uniqueidentifier literals and Windows GUID conventions.
• Uppercase where a system's collation or display convention requires it — UUID comparison is case-insensitive at the byte level.
• Quoted list for WHERE id IN (...) clauses and JSON arrays of test fixtures.

Store them as a native UUID type or as BINARY(16) where the database supports it. Storing 36-character strings in a VARCHAR column wastes space and slows every index that touches them.