What is a UUID?

A UUID (Universally Unique Identifier, also called a GUID — Globally Unique Identifier — in Microsoft's naming) is a 128-bit identifier, usually written as 32 hex digits in five groups: 8-4-4-4-12 characters. The full space is 2¹²⁸ ≈ 3.4 × 10³⁸ possible values — enough that you can generate UUIDs at a rate of 10 billion per second for the remaining lifetime of the sun and still use a negligible fraction of the space.

UUIDs are defined by RFC 4122 (and, for the newer time-ordered v6/v7, RFC 9562). Their appeal is that anyone, anywhere, can mint identifiers without coordinating with a central authority — no database sequence, no phone call to a registry.

The versions at a glance

Why v4 is the default

Version 4 draws 122 random bits (the other 6 encode the version and variant). The birthday bound says the chance of any collision among n generated v4 UUIDs is roughly n(n−1) / 2123. For a batch of 1,000 — the maximum this tool generates — that is about 1 in 10³¹. The stats line under your batch shows the exact figure for whatever count you generate.

v4 also leaks nothing: a v4 UUID tells an observer nothing about when or where it was created, unlike v1, whose 100 ns timestamp and 48-bit node are right there in the bits.

Why v7 for database primary keys

Random v4 primary keys are a well-known performance trap: in a B-tree index (Postgres, MySQL/InnoDB, SQLite), every insert lands at a random position, so the index page splits and fragments constantly. Version 7 starts with the current Unix time in milliseconds, so UUIDs generated close together sort close together — inserts append to the end of the index the way an auto-increment integer would, while still being globally unique and safe to generate on any client before the row exists. That is the main reason v7 (RFC 9562) exists, and why this tool offers it as a first-class variant.

Where you'll meet UUIDs

• Database primary keys — rows created on any client (mobile, edge, multi-region) without a sequence service.
• API and resource IDs — opaque identifiers in URLs that reveal neither counts nor ordering (v4) or that sort by creation time (v7).
• File and asset IDs — content-addressed or client-minted identifiers in object stores.
• Session and correlation tokens — request IDs that fan out across services and logs.
• Distributed systems — any place two nodes must name the same thing without talking to each other.

Common pitfalls

• v4 is not sortable. Random values do not sort by creation time — if you need that, use v7 (or v6).
• v1 leaks metadata. The 100 ns timestamp and node are readable by anyone holding the UUID. This tool uses a random per-page node instead of a real MAC address, so no hardware identity leaks.
• Case and braces are cosmetic. {8-4-4-4-12} with braces or UPPERCASE is the same UUID as lowercase with hyphens. Some APIs and config formats (COM, .NET, some YAML) expect braces; many databases expect bare lowercase. Format for the consumer, not for looks.
• Don't truncate. Every hex digit carries entropy. A “short UUID” (first 8 chars = 32 bits) collides after only ~4 billion of them — the birthday bound bites at 2¹⁶.
• UUIDs are not secrets. v4 is unpredictable, but a 128-bit identifier is not a 256-bit key. For tokens where guessing matters, use a dedicated secret of at least 128 random bits (a v4 is exactly that, but don't reuse identifier logic for authentication material).
• The nil UUID. All-zero 00000000-0000-0000-0000-000000000000 is a reserved value meaning “no identifier” — never generate or store it as a real ID.

Generate them from the command line instead

• Linux/macOS: uuidgen (or cat /proc/sys/kernel/random/uuid on Linux)
• Python: import uuid; uuid.uuid4() — uses os.urandom under the hood
• PowerShell: [guid]::NewGuid()
• JavaScript (browsers & Node 19+): crypto.randomUUID() — the same Web Crypto API this page uses

Nothing on this page leaves your browser: generation, formatting, validation, copying and downloading all happen locally, with no server round-trip and no storage of any kind.