UUID Generator

Anything that needs a unique ID without a central authority handing them out — database primary keys, tracking a request across distributed systems, session tokens, file names, API resource IDs. The key advantage over an auto-increment number is that two completely separate systems can generate IDs independently and never collide, without needing to coordinate through a shared database.

The fully-random variant: 122 bits of actual randomness (the rest of the 128 bits are fixed version/variant markers), with no timestamp, name, or other input involved. It's the most common type and the sensible default when you don't have a specific reason to pick a different version.

Something like 550e8400-e29b-41d4-a716-446655440000 — 32 hexadecimal characters grouped into five sections separated by hyphens (8-4-4-4-12). GUIDs use the exact same format.

v4 for general-purpose random IDs, v7 if the UUID will be a database primary key (it sorts by creation time, which keeps indexes efficient), and v5 if you need the same input to always produce the same UUID. v1 and v3 are mostly there for compatibility with older systems that specifically expect them.

36 characters in the standard format (32 hex digits plus 4 hyphens), or about 22 characters if you use the short Base58 format here — same identifier, just a denser encoding.

For random versions (v4, v7, v1's random portion), the odds are astronomically small — roughly 1 in 2^122 for v4. Deterministic versions (v5, v3) only produce the same UUID when you give them the exact same namespace and name, which is the intended behavior, not a collision.

It means a deterministic UUID: pick a namespace (DNS, URL, OID, X.500, or a custom one) and a name, and v5 (or the older v3) will always generate the exact same UUID for that combination — useful for creating a stable ID for something that already exists, like a URL or a filename, without having to store the mapping yourself.

Not here — a browser has no real MAC address to use, so the node portion is generated randomly each time (with its multicast bit set, per the UUID spec's own guidance for this exact situation). It carries no more privacy risk than v4.

For most new projects, yes. v7 embeds a timestamp so newly inserted rows stay sorted, which keeps database indexes efficient — v4's fully random ordering causes new rows to insert at random positions instead. Both are equally safe against collisions; v7 is simply the better fit for that specific job. ULID solves a similar sortability problem but is a different, non-UUID format entirely (26 characters, no hyphens) — worth knowing about, but not a drop-in UUID.

It's the same 128-bit UUID, just re-encoded into Base58 instead of the standard hex format — about 22 characters instead of 36, and fully reversible back to the exact original UUID. It carries exactly the same uniqueness guarantee as the UUID it was made from.

Yes — GUID is Microsoft's name for the same 128-bit identifier defined by the UUID standard. The terms are used interchangeably, especially around .NET, SQL Server, and PowerShell.

Paste it into the "Validate a UUID" field near the bottom of this page. It checks the format, tells you the version if it's a genuine one, and specifically flags the Nil UUID (all zeros) as the reserved special value it is rather than just calling it invalid.

Yes — it's called the Nil UUID, a specific reserved value meaning "no ID," defined in the same spec as every other UUID. It's valid, but it's not something a real generator would ever produce at random, so seeing it usually means it was set deliberately as a placeholder.

Java: UUID.randomUUID(). JavaScript (browser or modern Node.js): crypto.randomUUID(). Python: uuid.uuid4(). C#: Guid.NewGuid(). Via npm: the uuid package supports v1, v3, v4, v5, and v7. This tool covers the same versions if you'd rather generate some without writing code.