UUID Generator

What is a UUID?

A UUID (Universally Unique Identifier), also called a GUID, is a 128-bit value written as 32 hexadecimal digits in five hyphen-separated groups — 8-4-4-4-12, for example f47ac10b-58cc-4372-a567-0e02b2c3d479. The point is to mint an identifier that is unique without a central authority, so independent systems can each create IDs that will never collide. The 13th digit encodes the version and the 17th encodes the variant.

UUID versions at a glance

This tool generates v4, v7, v1 and v5. Versions 2 (DCE security), 6 (reordered v1) and 8 (custom) are rarely needed in application code. We deliberately omit the MD5-based v3 — MD5 is broken and unavailable in the browser’s crypto API — and offer the SHA-1-based v5 the spec prefers.

Which version should I use?

• Just need a unique ID? Use v4 (random) — it is the safe default.
• Database primary key? Use v7 — its leading timestamp keeps inserts ordered, avoiding the index fragmentation that random v4 keys cause.
• Need the same input to always map to the same ID? Use v5 with a namespace and name.
• Interoperating with an older system? Use v1.

Inspect a UUID

Paste any UUID to check it is valid and read its version, variant and (for v1/v7) embedded timestamp.

Are UUIDs really unique?

For random v4, the odds of a collision are astronomically small: with 122 random bits you could generate a billion UUIDs per second for about 85 years and still have only a roughly 50% chance of a single duplicate. In practice you can treat them as unique. A UUID is an identifier, not a secret, though — never use one as a password or security token.

From RFC 4122 to RFC 9562

UUIDs were first standardised by the IETF in RFC 4122 (July 2005), which defined versions 1 through 5 and registered the urn:uuid: namespace. Nearly two decades of real-world use — especially the explosion of distributed databases — exposed a gap: the original time-based formats were not designed to sort in creation order, which databases badly want. RFC 9562, published in May 2024, obsoletes RFC 4122 and answers that demand. It leaves the older versions intact and adds three new ones — v6 (a re-ordered v1), v7 (Unix-millisecond time plus randomness) and v8 (a free-form, vendor-defined layout) — along with the new Max UUID sentinel. It also declared the legacy Microsoft COM variant out of scope, so the modern versions apply only to the mainstream "variant 1" layout. In short: nothing you already use broke, and time-sortable IDs finally became a standard rather than a patchwork of incompatible homegrown schemes.

The anatomy of a UUID, bit by bit

All 128 bits are spoken for. Across the 16 octets, two small fields are reserved and the rest carry the payload — random bits, a timestamp, or a hash, depending on the version. The version sits in the four high bits of the seventh octet (the first hex digit of the third group), so it always reads as one of 1–8. The variant sits in the high bits of the ninth octet (the first hex digit of the fourth group), and for every standard UUID those bits are 10 in binary — which is why that digit is always 8, 9, a or b. Two reserved values fall outside the version scheme entirely: the Nil UUID, all zeros (00000000-0000-0000-0000-000000000000), meaning "no value," and the Max UUID, all ones (ffffffff-ffff-ffff-ffff-ffffffffffff), added by RFC 9562 to mark the end of a range.

Name-based UUIDs and the four standard namespaces

Versions 3 and 5 are deterministic: they hash a namespace UUID together with a name string, so the same pair always yields the same identifier on any machine, forever. That makes them ideal for stable IDs derived from existing keys — a URL, a filename, a domain — with no database lookup and no coordination. The only difference between the two is the hash: v3 uses MD5, v5 uses SHA-1, and the spec recommends v5. RFC 4122 defines four ready-made namespace UUIDs so independent systems agree on the same inputs:

For example, hashing the DNS namespace with the name example.com under v5 always produces the same UUID on every correct implementation — which is precisely why name-based UUIDs are reproducible across services without any shared state.

Why version 7 is winning for database primary keys

Random v4 UUIDs make poor clustered primary keys. Because each value is unpredictable, consecutive inserts scatter across the whole index; a B-tree must split pages all over the structure, the working set stops fitting neatly in cache, and write throughput degrades as the table grows. A v7 UUID fixes this by placing a 48-bit Unix-millisecond timestamp in the most significant bits, followed by random bits for uniqueness within the same millisecond. The values therefore increase over time and sort lexicographically in creation order, so new rows append to the "right edge" of the index — the same locality an auto-increment integer gives you, but keeping the decentralised, unguessable, merge-friendly nature of a UUID.

This is also why many teams reached for ULID before v7 existed. A ULID is a 128-bit, time-sortable identifier — a 48-bit millisecond timestamp plus 80 random bits — rendered as 26 Crockford base-32 characters instead of hexadecimal. It solves the same locality problem, but it is not an IETF standard and its text form is not a valid UUID. Now that RFC 9562 has standardised v7 with essentially the same design, new projects can get time-ordered IDs while remaining fully UUID-compatible, which is steadily pushing v7 ahead of both random v4 keys and ULID.

The numbers behind "unique," and the privacy footnotes

The collision odds for v4 are easier to grasp with exact figures. Six of the 128 bits are fixed for the version and variant, leaving 122 random bits — about 5.3 × 10³⁶ (5.3 undecillion) distinct values. By the birthday problem, you would need roughly 2.71 quintillion UUIDs before a single collision became more likely than not, and even generating 103 trillion of them leaves the chance of any duplicate at about one in a billion — far more identifiers than most organisations will ever mint across every database they own. The one caveat: this holds only with a good random source. A v4 produced by a weak or improperly seeded pseudo-random generator can and does collide.

Two cautions are worth repeating. First, a UUID is an identifier, not a secret — never use one as a password, API key or session token, where you want a value that is both unique and unguessable from a dedicated cryptographic source. Second, the time-based versions can leak information: a classic v1 UUID embeds both the creation timestamp and the generating machine's network MAC address, which famously helped investigators trace the author of the 1999 Melissa virus. That is exactly why this generator builds v1 with a random node rather than a real MAC, and why v4 or v7 are the safer defaults whenever an identifier might be exposed publicly. Finally, "GUID" — the term Microsoft uses — is simply another name for a UUID; the only wrinkle is that some legacy Microsoft GUIDs serialise parts of the value in a different byte order, so always compare them as the canonical 8-4-4-4-12 text string rather than as raw bytes.

Storing and formatting UUIDs in practice

A UUID is conceptually 16 bytes, but it is usually written as the 36-character 8-4-4-4-12 string. How you store it matters. Keeping it as raw 16 bytes — PostgreSQL's native uuid type, or BINARY(16) in MySQL — uses less than half the space of a 36-character text column and indexes faster; storing it as VARCHAR(36) is convenient but wasteful at scale. The canonical text form is lower-case, although the spec requires parsers to accept upper-case too, so treat comparisons as case-insensitive and normalise values on the way in. The hyphens are purely cosmetic grouping — some systems strip them to save four characters — but the canonical, interoperable form keeps them.

One design caution: because v1, v6 and v7 embed a timestamp, and v4 is unguessable, people sometimes assume any UUID in a URL is safe to expose. It is — for uniqueness — but a UUID is still an identifier, not an authorisation. If access control relies on the value staying secret ("anyone with the link can view"), prefer v4 or a dedicated random token over the time-based versions, since a leaked v1 or v7 reveals roughly when the record was created and, for v1, potentially the machine that made it.

When a UUID is the wrong tool

UUIDs are not free. At 128 bits they are four times the size of a 32-bit integer and twice that of a 64-bit one, which adds up across billions of rows and every foreign key that references them. They are also awkward for humans — nobody reads a support ticket number aloud as "f47ac10b-58cc…". If your IDs live inside a single database that already provides a reliable auto-increment sequence, and you do not need to generate IDs offline, on multiple nodes, or before the row is inserted, a plain sequential integer is smaller, faster and more legible. Reach for a UUID precisely when you need decentralised generation — IDs minted by clients, by multiple servers, or merged from separate systems without coordination — which is where its no-central-authority guarantee earns its keep. When you do, prefer v7 so you keep that guarantee without sacrificing the index locality a database relies on.

Frequently asked questions

Are UUIDs guaranteed to be unique?

Not mathematically guaranteed, but for practical purposes yes. A version-4 UUID has 122 random bits — you would need to generate billions per second for many years before a collision became even remotely likely. Version 5 is deterministic, so the same namespace and name always produce the same UUID by design.

Which UUID version should I use?

Use version 4 (random) for general unique IDs. Use version 7 if you want IDs that sort by creation time — ideal as database primary keys, since they avoid the index fragmentation random v4 keys cause. Use version 5 when you need a reproducible ID derived from a name. Version 1 is mainly for legacy compatibility.

Is a UUID secure or hard to guess?

A version-4 UUID is unpredictable enough to be hard to guess, but a UUID is an identifier, not a secret. Do not use one as a password, session token, or security key — generate a dedicated cryptographic secret for those.

What is the difference between v4 and v7?

Both are unique, but v7 embeds a millisecond timestamp at the front, so a list of v7 UUIDs sorts in creation order. v4 is fully random and has no order. Use v7 for database keys (better index locality) and v4 when ordering does not matter.

Why is there no version 3 here?

Version 3 is name-based but uses MD5, which is cryptographically broken, and the browser’s Web Crypto API does not expose MD5. We offer version 5, the SHA-1-based equivalent that the spec recommends instead.

Are the UUIDs generated privately?

Yes. Everything is generated locally in your browser using the built-in Web Crypto API — nothing is sent to a server, and it works offline once the page has loaded. Version 1 uses a random node, so your network hardware address is never exposed.

Related tools

• SHA Hash Generator
• Unix Timestamp Converter
• Base64 Encoder / Decoder
• JSON Formatter & Validator

See all developer & data conversions →