What a UUID is
A UUID (Universally Unique Identifier), also called a GUID (Globally Unique Identifier) in some ecosystems, is a 128-bit identifier formatted as 32 hexadecimal digits in five groups separated by hyphens (8-4-4-4-12) — for example, 550e8400-e29b-41d4-a716-446655440000. The format and generation rules are defined by RFC 9562, which obsoletes the older RFC 4122. Depending on the version, practical uniqueness comes from cryptographic randomness, timestamps combined with additional state/randomness, or a deterministic hash of a namespace-and-name pair — achieving practical uniqueness without central coordination or a database lookup, which is the entire point.
Which UUID version should I use?
v4 (random) is the right default for almost everything — a general-purpose unique ID with no other requirements. 122 bits of cryptographically random data make collisions practically impossible.
v7 (sortable, timestamp-based) is increasingly the better choice specifically for database primary keys and similar cases where insertion order matters: a v7 UUID starts with a 48-bit Unix millisecond timestamp, so it's time-ordered as plain byte or string comparisons — with no separate "created at" column needed just to get chronological order. Two UUIDs generated in genuinely different milliseconds always sort correctly by that timestamp alone; RFC 9562 treats what happens WITHIN the same millisecond as an implementation choice rather than a guarantee inherent to the version itself, so a naive implementation could produce two same-millisecond UUIDs in either order. This tool's own generator specifically preserves strict ordering within the same loaded page instance, including batch generation, using the monotonic-random method RFC 9562 \u00a76.2 itself describes — that state lives only in this page's own JavaScript memory, so it doesn't carry across a page reload, a new tab, or any other independent instance of this tool. Across independent machines or generator instances more broadly, chronological ordering still depends on their clocks being sufficiently synchronized with each other. v4's uniform randomness means it has no inherent order at all, which can hurt index locality in a database at scale.
v1 (timestamp-based) is the older timestamp-based format v7 was designed to improve on — it embeds a timestamp too, but in a different (Gregorian-epoch-based, not sortable as plain bytes) layout, plus a node ID historically meant to be a MAC address. This tool always generates the node ID randomly (with the bit RFC 9562 requires to mark it as not a real hardware address) rather than reading anything from your actual device, since a browser has no way to read a MAC address anyway and doing so would leak identifying hardware information even if it could.
v3 and v5 (name-based) are deterministic: the same namespace UUID plus the same name string always produces the exact same UUID. Useful when you need a stable, repeatable ID derived from an existing identifier (a URL, a domain name, an internal record ID) rather than a fresh random one — the same input always maps to the same output, which a v4 UUID could never do. RFC 9562 is explicit: "Where possible, UUIDv5 SHOULD be used in lieu of UUIDv3", pointing to MD5's own known security considerations. v3 is retained here mainly for compatibility with systems that specifically require MD5-based UUIDs. RFC 9562 recommends v5 instead wherever possible because of MD5's known security limitations.
Inspecting an existing UUID
Switch to Inspect above and paste a UUID — canonical hyphenated, with no hyphens, or wrapped in braces, in any letter case — to see its version, its RFC 9562 variant bits, and — for v1, v6, and v7 specifically, since those are the standardized versions that embed one — the timestamp encoded inside it. This can be useful for debugging: given a UUID from a log line or a database row, what timestamp is embedded in it, and what approximate generation time does that represent?
Frequently asked questions
Are UUIDs actually guaranteed to be unique?
Not with mathematical certainty — RFC 9562 itself is explicit that a UUID doesn't offer absolute mathematical uniqueness, only a probability low enough to be negligible for the application's own tolerance for collisions. For a v4 UUID specifically: with 122 random bits, the collision probability remains negligible for ordinary workloads; reaching roughly a 50% chance of at least one collision (the standard "birthday problem" threshold) would require about 2.7 quintillion independently generated UUIDs. Name-based UUIDs (v3/v5) work the same way as each other: the same namespace and name always produce the same UUID. Distinct namespace-and-name pairs are expected to produce different UUIDs with very high probability, although hash collisions are theoretically possible. Unlike v4, v3 and v5 are deterministic and do not rely on random generation at all.
Can I tell what generated a UUID, or extract information from it?
Only limited information, and only for certain versions. A v1, v6, or v7 UUID embeds a timestamp (this tool's Inspect view decodes it). v1 and v6 also contain a 48-bit node field; in legacy UUIDs this may be derived from a real IEEE 802/MAC address and can expose host-related information — RFC 9562 itself warns about this privacy risk. This tool's own v1 generator always uses a cryptographically random node value instead (never a real hardware address), so a UUID generated here never exposes your device's actual MAC address — but that guarantee is specific to what this tool generates, not a universal property of every v1 or v6 UUID you might encounter elsewhere. A v4 UUID embeds nothing beyond its own random bits; there's no way to determine when, where, or by what it was generated.
Is it safe to use a UUID as a security token (a password reset link, an API key)?
No. RFC 9562's own security guidance is direct on this: implementations "SHOULD NOT assume that UUIDs are hard to guess," and "MUST NOT be used as security capabilities" (identifiers whose mere possession grants access) — a UUID should not be used as a bearer security token such as a password-reset secret or an API key. Use a purpose-built, cryptographically random token with sufficient entropy instead. Regardless of version, a UUID itself should never be the bearer secret or security capability. If a UUID must be used as part of a security-related operation, RFC 9562 recommends UUIDv4.
Why do some UUIDs start with specific characters, like "4" or "7" in the third group?
That's the version number, RFC 9562's own way of marking which generation algorithm produced a given UUID. For UUIDs using the RFC 9562 variant, the first hex digit of the third group contains the version number (so a v4 UUID's third group starts with "4", a v7 UUID's with "7", and so on). Nil and Max UUIDs are special cases and do not have a version. This tool's own Inspect view reads this directly — and correctly reports no version at all for Nil/Max or for a reserved (non-RFC-9562) variant, rather than misreading that nibble as a version number where it doesn't actually mean one.
Sources
Last reviewed: . UUID generation uses the browser's native Web Crypto API for randomness (never Math.random()) and SHA-1 (for v5); v3's MD5 step uses a small, self-contained implementation, since Web Crypto deliberately doesn't support MD5.