{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

Family{{ computation.ok ? computation.values.profile : '—' }} Variant{{ hasUuid ? currentGeneration.variant : '—' }}
Use v1/v3/v6 for compatibility-specific work; prefer v4, v5, or v7 for common new designs.
Use only when the receiving system expects uppercase GUID-style text.
{{ uppercase ? 'On' : 'Off' }}
The canonical UUID and URN remain dashed lowercase values.
{{ remove_dashes ? 'On' : 'Off' }}
Useful for Windows or COM inputs that explicitly request {uuid} syntax.
{{ include_braces ? 'On' : 'Off' }}
Generated UUID
{{ hasUuid ? formattedUuid : 'Generate a UUID to populate this artifact.' }}
{{ row.label }}{{ row.value }}
{{ computation.values.profile }} fit guide
Core mechanism

{{ computation.values.mechanism }}

Good fit

{{ computation.values.recommended_use }}

Handling note

{{ computation.values.privacy_note }}

The chart renderer is unavailable. The exact bit counts remain available in the fit guide and CSV export.

#UUIDVersionGeneratedCopy
{{ row.id }}{{ row.formatted }}{{ row.profile }}{{ row.generatedAtDisplay }}
Universally Unique Identifier (UUID) Decoder Decode a UUID into canonical text and inspect its version, variant, bit fields and embedded time with checks for sentinel or legacy layouts.
SemVer Bump Required Checker Check release notes and commit subjects for the required SemVer bump, then verify whether a planned version covers the strongest change signal.
Secure Password Generator Generate a unique password in your browser with adjustable character rules, unbiased random selection, and clear strength estimates.
Credit Card Number Generator Generate reproducible Luhn-valid card-shaped fixtures for form testing, with synthetic prefixes and optional CVV or expiry fields.

Records often need identifiers before a central database can assign the next number. Separate services, offline devices, imports, test fixtures, and event streams may all create records independently. A universally unique identifier (UUID) gives each record a 128-bit value that can be generated without first coordinating with one shared counter.

The familiar dashed text contains 32 hexadecimal digits arranged in an 8-4-4-4-12 pattern. Six bits identify the UUID version and variant; the remaining 122 bits carry random data, a name hash, or time-related fields according to the selected version. “GUID” is a common name for the same general kind of identifier, especially in Microsoft systems.

Version
The four-bit marker that identifies how the UUID payload was constructed.
Variant
The layout-family marker. Current IETF UUID versions use the RFC 9562 variant.
Namespace
A UUID combined with a name to create a repeatable version 3 or version 5 value.
Canonical form
The lowercase dashed representation of the underlying 128-bit value.

Version choice depends on what must remain stable or visible. Version 4 is a good general choice for opaque random identifiers. Version 5 maps the same namespace and name to the same UUID, which helps imports and cross-system keys. Version 7 begins with Unix time in milliseconds, so values broadly sort by creation time and work well for new event or database identifiers.

Need Version Important tradeoff
General opaque record ID v4 Random and non-deterministic, with no chronological order.
Stable mapping from a name v5 Predictable by anyone who knows the namespace and name.
Legacy name mapping v3 Uses MD5 and is mainly for compatibility with an established mapping.
New time-ordered ID v7 Reveals creation time and is not strictly ordered within one millisecond.
Classic or reordered time layout v1 or v6 Retains time, clock-sequence, and node-like fields; use when compatibility requires them.

A UUID is an identifier, not a password, secret, or authorization decision. Its purpose is to make accidental duplication extremely unlikely under the rules of the chosen version. Applications still need unique constraints, access control, and a recovery plan for malformed or duplicate values.

Formatting changes only the text representation. Uppercase letters, removed dashes, or surrounding braces may satisfy a receiving system, but they do not create a different 128-bit UUID. Keep the canonical value when systems need to compare or validate identifiers consistently.

How to Use This Tool:

Choose the UUID version from the receiving system’s identity and ordering requirements before changing its display style.

  1. Select UUID version. Prefer v4 for a fresh opaque ID, v5 for a repeatable name mapping, or v7 for a new time-ordered identifier. Use v1, v3, or v6 only when compatibility calls for that layout.
  2. For v3 or v5, enter the stable Name and choose DNS, URL, OID, X500, or supply a canonical namespace UUID. The same version, namespace, and name reproduce the same value.
  3. Generate the UUID, then inspect Canonical UUID, Version profile, and Variant. For v7, compare the embedded time with the expected creation time.
  4. Apply uppercase, dash removal, or braces only when the destination explicitly requires that display form. Copy the formatted value, but retain the canonical form for reliable comparison.

Interpreting Results:

Canonical UUID is the authoritative dashed lowercase value. Formatted UUID reflects display options, and the URN adds the urn:uuid: prefix to the canonical form. The decoded version and variant should agree with the profile you selected.

For v3 and v5, repeatability is the main result: identical namespace and name inputs should reproduce the same UUID. For v4, each generation should be fresh. For v7, the first 48 bits encode Unix milliseconds, but random data in the remaining payload means two values created in one millisecond are not guaranteed to appear in generation order.

The generation ledger is kept only for the current browser session and is capped at 20 entries. A successful generation does not prove that a remote database accepted the ID or that no other system has already stored the same value; enforce uniqueness where records are committed.

Technical Details:

Every supported UUID occupies 128 bits. The version field uses 4 bits and the RFC variant uses 2, leaving 122 payload bits. The meaning and placement of those payload bits distinguish random, name-based, and time-based versions.

Formula Core:

The payload count subtracts the two required marker fields from the 128-bit UUID.

P = 128 − 4 − 2 = 122

Here, P is the number of timestamp, hash, random, clock-sequence, and node bits available after the version and RFC variant markers are reserved.

Mechanism Core:

Version Payload before markers Generation mechanism
v1 60-bit Gregorian timestamp, 14-bit clock sequence, 48-bit node field Classic time-based layout.
v3 122 retained hash bits MD5 over the namespace UUID followed by the UTF-8 name, then version and variant bits are set.
v4 122 random bits Sixteen cryptographically strong random bytes are generated, then the version and variant bits replace six positions.
v5 122 retained hash bits SHA-1 over the namespace UUID followed by the UTF-8 name, then version and variant bits are set.
v6 60-bit Gregorian timestamp, 14-bit clock sequence, 48-bit node field The v1 timestamp is reordered from most to least significant for better time locality.
v7 48-bit Unix-millisecond timestamp, 74 random bits The timestamp occupies the most significant 48 bits; random bytes fill the remaining payload in this generator.

The canonical string contains 36 characters: 32 hexadecimal digits and 4 dashes. Removing dashes produces 32 characters; braces add 2 characters to either representation. Case changes hexadecimal lettering only and never changes the decoded bytes.

Rule Core:

  • v3 and v5 require a non-empty name of at most 512 characters plus DNS, URL, OID, X500, or a canonical 8-4-4-4-12 namespace UUID.
  • Namespace aliases are case-insensitive and resolve to their standard namespace UUIDs before hashing.
  • v1, v4, v6, and v7 ignore the name and namespace fields because their payloads are not name-derived.
  • Display options run after canonical generation, so they do not affect version bits, variant bits, or deterministic name mapping.

Random v4 and v7 bytes come from the browser’s cryptographic random source. v7 uses the current clock for its millisecond field. Clock accuracy therefore affects the embedded time even though the random tail remains independently generated.

Privacy and Accuracy Notes:

  • v1 and v6 expose time and node-like fields; v7 exposes creation time in milliseconds.
  • v3 and v5 are deterministic. A person who knows the namespace and name can reproduce the UUID, so these values do not conceal sensitive names.
  • v4 is opaque by design, but a UUID still must not replace a password, API key, session secret, or access-control check.
  • Generation occurs in the browser. Required browser resources or cryptographic randomness can be unavailable, in which case no UUID is produced.

References: