A Universally Unique Identifier (UUID) is a 128-bit value, typically written as 32 hex digits in the form 8-4-4-4-12, designed so that generating one independently anywhere is astronomically unlikely to collide with another. RFC 9562 (2024) is the current spec; it obsoletes the older RFC 4122 but keeps every version RFC 4122 defined.

What's the difference between a UUID and a GUID?

Nothing, structurally. GUID (Globally Unique Identifier) is Microsoft's name for the same 128-bit layout — every UUID this tool generates is also a valid GUID.

Which version should I use?

v4 for most things — it's pure randomness with no timestamp or hardware leak. v7 if you need the UUID to sort roughly by creation time (e.g. as a database primary key, where it keeps index writes sequential instead of scattered). v5 if the same input must always produce the same UUID (deterministic, name-based). v1/v6 exist for legacy compatibility but embed a timestamp and a node id — see the FAQ below on what that leaks.

Is UUID v4 cryptographically secure?

Yes — this tool's v4 output comes from the Web Crypto API's CSPRNG (crypto.getRandomValues, the same source crypto.randomUUID() uses), not Math.random().

Why does my UUID v1 leak my MAC address?

RFC 9562 defines v1's last 48 bits as a "node id", and the traditional implementation fills it with the generating machine's real network MAC address. Every v1 UUID from that machine then shares that same value forever, which is both a stable tracking identifier and, combined with the embedded timestamp, tells an observer exactly when and on which machine each ID was made. This tool never uses a real MAC — it fills the node id with random bits per RFC 9562 §6.7's own recommendation, and marks them with the "multicast" bit so they're never mistaken for a real one. Turn off "randomize node ID" below to see what a real, MAC-based v1 implementation would expose: the same node value on every UUID.

Can a UUID v5 be reversed back to its name?

No. v5 runs the namespace and name through SHA-1, and a hash can't be reversed — you cannot recover "example.com" from a v5 UUID alone. What you can do is verify a guess: if you think a given v5 UUID was built from a specific namespace and name, generate that combination here and compare. The UUID decoder does exactly this for a UUID someone else gave you.

UUID v7 vs v4 — which is actually better?

Neither, universally — they trade one property for another. v7 embeds a millisecond timestamp in its top bits, so v7 UUIDs sort close to insertion order; that keeps a B-tree index appending at one edge instead of writing all over the tree, which is faster for many databases. The cost is the same one v1 has at a smaller scale: v7 reveals roughly when each row was created, and under very high write concurrency the timestamp-clustered keys can become a hot spot some engines handle worse. v4 has no such leak and no hot spot, but scatters index writes randomly. Pick v7 for a primary key where insert locality matters and the creation time isn't sensitive; pick v4 otherwise.

Are these UUIDs generated on a server?

No — every UUID here is generated locally in your browser. Nothing is transmitted or logged.

This tool runs entirely in your browser. Nothing you paste is uploaded.

How you can check →

UUID Generator

Generators

Generate any UUID version RFC 9562 defines — v1 through v8, plus the Nil and Max sentinels — one at a time or in bulk. Runs entirely in your browser.

Have a UUID someone else gave you instead of one to generate? The UUID decoder reads its version, variant, and — for v1/v6/v7 — the timestamp inside it.

Version

Output

—

Output format

Bulk generate

Count Max 1,000 Export as

Results

Code for this version

UUID structure

A UUID is written as 32 hexadecimal digits grouped as 8-4-4-4-12 (e.g. xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx). The version is encoded in the first digit of the third group (M above), and the variant is encoded in the first bits of the fourth group (N). This tool is built directly from RFC 9562, the current specification (May 2024). It obsoletes the older RFC 4122 — still what most existing library documentation cites — but keeps every version RFC 4122 defined and adds v6, v7 and v8.

UUID v1 — time-based

Encodes a 60-bit timestamp (100-nanosecond ticks since 1582-10-15) and a 48-bit "node id", traditionally the machine's real MAC address. That makes every v1 UUID from one machine share a stable, trackable node value, plus reveal exactly when it was created — see the FAQ below. This tool randomizes the node id by default, per RFC 9562's own recommendation.

UUID v3 — name-based (MD5)

Deterministic: hashes a namespace UUID plus a name string with MD5. The same namespace and name always produce the same UUID, which makes v3 useful for generating a stable ID from something you already have (a URL, a filename) without a lookup table. RFC 9562 recommends v5 over v3 wherever collision resistance matters — MD5 is a weaker hash than SHA-1 — but v3 is still what some legacy systems expect.

UUID v4 — random

122 bits of CSPRNG output (the other 6 are the fixed version and variant bits). No timestamp, no hardware id, nothing to reconstruct — the default for most use cases, and the version this page opens on.

UUID v5 — name-based (SHA-1)

The same idea as v3, hashed with SHA-1 instead of MD5. RFC 9562 recommends v5 over v3 for new work. Deterministic, one-way — see "Can a UUID v5 be reversed" below.

UUID v6 — sortable time-based

The same fields as v1 — same timestamp, same node id — reordered so the bits sort high-to-low. A v6 UUID therefore sorts lexicographically by creation time, fixing v1's one real flaw (index locality) without changing anything it encodes, including the node-id privacy question above.

UUID v7 — sortable, Unix-epoch

The top 48 bits are milliseconds since 1970-01-01, the rest CSPRNG. Sortable like v6, but against the epoch everything else already uses, and with no node id to leak. This is what most "use a UUID as a database primary key" advice now means — see the tradeoff against v4 in the FAQ.

UUID v8 — custom / vendor

RFC 9562 fixes only the version and variant bits for v8 and leaves the rest free-form for a private use case — there is no single canonical "v8 UUID". This generator fills the free bits with the same CSPRNG source as v4. Treat v8 output here as a correctly-shaped container, not a match for any particular vendor's own v8 layout.

Nil and Max

The Nil UUID (00000000-0000-0000-0000-000000000000) and Max UUID (all fs) are RFC 9562-defined sentinels — useful as an explicit "no value" or "unbounded" marker in a schema that otherwise stores UUIDs.

Why not v2?

RFC 9562 keeps v2 (DCE Security) for compatibility but calls it rarely used. It needs a local domain and a POSIX UID/GID, which most callers don't have, and no mainstream UUID library — including Node's own uuid package — implements it. It's left out of this generator for that reason.

Common use cases

Primary keys for database rows, generated client-side or server-side
Idempotency keys for API requests
Correlation/trace IDs for distributed logging
Deterministic IDs from an existing string (v5) instead of a lookup table
Unique filenames or object storage keys

Frequently asked questions

What is a UUID?: A Universally Unique Identifier (UUID) is a 128-bit value, typically written as 32 hex digits in the form 8-4-4-4-12, designed so that generating one independently anywhere is astronomically unlikely to collide with another. RFC 9562 (2024) is the current spec; it obsoletes the older RFC 4122 but keeps every version RFC 4122 defined.
What's the difference between a UUID and a GUID?: Nothing, structurally. GUID (Globally Unique Identifier) is Microsoft's name for the same 128-bit layout — every UUID this tool generates is also a valid GUID.
Which version should I use?: v4 for most things — it's pure randomness with no timestamp or hardware leak. v7 if you need the UUID to sort roughly by creation time (e.g. as a database primary key, where it keeps index writes sequential instead of scattered). v5 if the same input must always produce the same UUID (deterministic, name-based). v1/v6 exist for legacy compatibility but embed a timestamp and a node id — see the FAQ below on what that leaks.
Is UUID v4 cryptographically secure?: Yes — this tool's v4 output comes from the Web Crypto API's CSPRNG (crypto.getRandomValues, the same source crypto.randomUUID() uses), not Math.random().
Why does my UUID v1 leak my MAC address?: RFC 9562 defines v1's last 48 bits as a "node id", and the traditional implementation fills it with the generating machine's real network MAC address. Every v1 UUID from that machine then shares that same value forever, which is both a stable tracking identifier and, combined with the embedded timestamp, tells an observer exactly when and on which machine each ID was made. This tool never uses a real MAC — it fills the node id with random bits per RFC 9562 §6.7's own recommendation, and marks them with the "multicast" bit so they're never mistaken for a real one. Turn off "randomize node ID" below to see what a real, MAC-based v1 implementation would expose: the same node value on every UUID.
Can a UUID v5 be reversed back to its name?: No. v5 runs the namespace and name through SHA-1, and a hash can't be reversed — you cannot recover "example.com" from a v5 UUID alone. What you can do is verify a guess: if you think a given v5 UUID was built from a specific namespace and name, generate that combination here and compare. The UUID decoder does exactly this for a UUID someone else gave you.
UUID v7 vs v4 — which is actually better?: Neither, universally — they trade one property for another. v7 embeds a millisecond timestamp in its top bits, so v7 UUIDs sort close to insertion order; that keeps a B-tree index appending at one edge instead of writing all over the tree, which is faster for many databases. The cost is the same one v1 has at a smaller scale: v7 reveals roughly when each row was created, and under very high write concurrency the timestamp-clustered keys can become a hot spot some engines handle worse. v4 has no such leak and no hot spot, but scatters index writes randomly. Pick v7 for a primary key where insert locality matters and the creation time isn't sensitive; pick v4 otherwise.
Are these UUIDs generated on a server?: No — every UUID here is generated locally in your browser. Nothing is transmitted or logged.

UUID Decoder

Paste a UUID to see its version, variant, and — for v1/v6/v7 — its timestamp.

Random Number Generator

Generate random integers or decimals in a custom range.

Password Generator

Generate a strong password with real entropy and per-algorithm crack times — or one that matches a site's own rules.

Last updated 18 September 2026.