Universally Unique Identifier (UUID) Generator

UUID version:

Use v4 for general IDs, v7 for sortable creation time, or v3/v5 with name and namespace.

Name:

Enter a stable key such as example.com, tenant-id, or customer-42.

Namespace:

Accepted: DNS, URL, OID, X500, or a canonical UUID namespace.

Uppercase output:

Turn on for uppercase hex output in copied and exported values.

Remove dashes:

Use when a storage field expects 32 hex characters with no separators.

Wrap in braces:

Produces {uuid}; leave off for standard RFC-style text.

Metric	Value	Copy
{{ r.label }}	{{ r.value }}
No data yet. Generate a UUID.

Field	Hex	Meaning	Copy
{{ r.field }}	{{ r.hex }}	{{ r.meaning }}
No UUID yet. Generate a UUID.

#	UUID	Version	Copy
{{ row.index }}	{{ row.uuid }}	{{ row.versionDisplay }}
No history yet.

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Distributed systems often need identifiers before a central database can hand out the next number. Imports, background jobs, offline devices, test fixtures, message queues, and separate services may all create records independently, then merge or compare them later. A UUID gives each record a 128-bit label with a standard text form, so coordination is usually unnecessary at the moment the ID is created.

The familiar five-group string is more structured than it first appears. UUID text is made from hexadecimal digits, with reserved bits that identify the version and variant. Those markers explain whether the remaining bits are random, derived from a stable name, or carrying timestamp information. The word GUID is often used for the same kind of identifier, especially in Microsoft and Windows contexts.

Canonical UUID: The standard dashed lowercase representation of the 128-bit value, such as an 8-4-4-4-12 group layout.
Version: The UUID family marker. It changes how the rest of the bits should be interpreted.
Variant: The broad layout marker. Modern generated UUIDs normally use the RFC 9562 layout family.
Namespace: A UUID domain combined with a name to produce repeatable version 3 or version 5 values.

Version choice is a design decision, not a quality score. Random UUIDs are useful when the ID should be opaque. Name-based UUIDs are useful when the same input should always produce the same identifier. Time-ordered UUIDs help logs and databases group newer values together, but they reveal more about when an ID was created.

Common UUID version choices
Need	Usual UUID Family	Tradeoff
Fresh opaque record IDs	v4 random	No embedded name or time, but no natural chronological order.
Repeatable IDs from stable names	v5 or legacy v3 name-based	Same namespace and name reproduce the same value, so the ID is predictable from those inputs.
IDs that group by creation time	v7, or v6 for reordered time-based layouts	Time fields help ordering, but the identifier is less opaque than a random-only value.

The text groups are display-friendly slices of one 128-bit value; the version and variant bits live inside those groups.

Formatting choices are separate from identity. Removing dashes, switching to uppercase, or wrapping a value in braces can satisfy a database field, API client, Windows GUID prompt, or legacy import format. Those changes do not create a new UUID family or change the canonical value underneath.

A UUID is an identifier, not a secret and not proof that a record exists. Version 4 values are hard to guess in normal identifier use, but access control still belongs in authentication, authorization, and token design. Time-based and name-based UUIDs need extra care because timestamps, namespaces, and stable names can reveal relationships that a random-only ID would hide.

How to Use This Tool:

A default random UUID appears when the page loads. Choose the version and text format before copying the value into the system that needs it.

Set UUID version. Use Version 4 - Random for ordinary fresh IDs, Version 7 - Unix time sortable for time-friendly event records, Version 5 - SHA-1-name for repeatable name mappings, and Version 1, Version 3, or Version 6 only when that family is specifically needed.
For Version 3 - MD5-name or Version 5 - SHA-1-name, fill in Name and Namespace. The namespace can be DNS, URL, OID, X500, a 32-character hexadecimal namespace, or a UUID-shaped namespace.
Press Generate UUID when the settings are valid. The latest value appears in the summary, and the generated entry is added to UUID History. If a name-based setup is missing a name or valid namespace, the warning explains what to fix before the action can run.
Open Advanced only when the receiving system needs a different text shape. Uppercase output, Remove dashes, and Wrap in braces change the displayed and copied value without changing the canonical UUID.
Check UUID Details for the formatted value, canonical value, URN, version, generation profile, variant, no-dash form, uppercase form, and formatted length. Time-based versions also show decoded time or node-related rows when available.
Use UUID Anatomy to split the canonical value into the five UUID text groups and see which segment carries the version or variant marker.
Open JSON or the table copy/download actions when you need a portable record of the current value. UUID History keeps the latest 20 generated entries for the current page session, so copy or export it before reloading.

For repeatable name-based IDs, keep the same version, namespace, and name. Display toggles should only change UUID (formatted); UUID (canonical) should stay fixed.

Interpreting Results:

Start with UUID (canonical) when identity matters. It is the lowercase dashed UUID before display-only formatting. Use UUID (formatted) for the exact text you plan to paste into another system, especially when braces, uppercase, or dash removal are turned on.

The Version and Generation profile rows explain the family behind the value. They are not quality scores. A version 4 UUID is usually the right opaque default, a version 5 UUID is repeatable from its inputs, and a version 7 UUID carries creation-time information for broad chronological sorting.

UUID outputs and interpretation cautions
Output	Use It For	Do Not Assume
`UUID (formatted)`	Copy-ready text after the selected formatting options.	That formatting changed the underlying identifier.
`UUID (canonical)`	The stable UUID value in standard dashed lowercase form.	That the value is registered, stored, or known anywhere else.
`Variant`	The broad layout family bits, normally `RFC 9562` for generated values.	That the variant describes the generation method by itself.
`v7 Unix time` rows	Confirming the millisecond timestamp embedded in a version 7 UUID.	Strict sequencing for values created in the same millisecond.
`v1` or `v6` decoded rows	Inspecting timestamp, clock sequence, and node-like fields.	That those fields are suitable for privacy-sensitive opaque IDs.

Use the history as a working scratchpad, not as a registry. It helps you compare recent generated values and copy the one you want, but uniqueness in your real application still depends on storing the chosen ID once and enforcing the right database or application constraints.

The main false-confidence risk is treating any UUID as a bearer secret. If knowing the string grants access, use a purpose-built secret token and normal permission checks instead of relying on UUID shape or collision odds.

Technical Details:

RFC 9562 defines UUIDs as 128-bit values with reserved version and variant fields. The canonical text form has 32 hexadecimal digits separated as 8-4-4-4-12. The version marker sits in the third group, and the variant marker begins in the fourth group.

Different UUID families fill the remaining bits differently. Random-family UUIDs use entropy plus reserved bits, name-based UUIDs hash a namespace and name, and time-based UUIDs place timestamp data into defined fields. That difference is why the same text length can represent very different privacy, repeatability, and sorting behavior.

Structure and Rule Core:

UUID version structure and rules
Version	Core Mechanism	Technical Note
v1	Gregorian time-based layout with timestamp, clock sequence, and node fields.	Decoded rows can show UTC time, local time, clock sequence, node bytes, and node type.
v3	Deterministic namespace-plus-name UUID using the MD5-based version 3 family.	The same namespace and name reproduce the same canonical UUID.
v4	Random-family UUID with reserved version and variant bits.	Best for opaque general identifiers when no embedded time or name relationship is wanted.
v5	Deterministic namespace-plus-name UUID using the SHA-1-based version 5 family.	Useful for stable import keys, fixture IDs, and repeatable domain mappings.
v6	Reordered Gregorian time-based layout.	The timestamp is rearranged to make sorting friendlier than classic v1 while keeping time-based fields.
v7	Unix-millisecond time first, followed by random fields and reserved bits.	Generated v7 values use random fields after the millisecond timestamp rather than a same-millisecond monotonic counter.

Field Anatomy:

Canonical UUID field anatomy
Canonical Group	Length	What to Check
`time_low`	8 hex characters	First field. In time-based families, it is part of the timestamp layout.
`time_mid`	4 hex characters	Middle field. In name-based or random families, it is hash or random-derived text.
`time_hi_and_version`	4 hex characters	Contains the version marker, such as `4` for v4 or `7` for v7.
`clock_seq_hi_variant` and `clock_seq_low`	4 hex characters total	Carry the variant marker and a clock-sequence or continuation field.
`node_or_random`	12 hex characters	Node bytes for time-based layouts, random tail for v4/v7, or hash-derived tail for v3/v5.

Name-based UUIDs rely on namespace separation. The standard shortcuts resolve to fixed namespace UUIDs: DNS is 6ba7b810-9dad-11d1-80b4-00c04fd430c8, URL is 6ba7b811-9dad-11d1-80b4-00c04fd430c8, OID is 6ba7b812-9dad-11d1-80b4-00c04fd430c8, and X500 is 6ba7b814-9dad-11d1-80b4-00c04fd430c8. A custom namespace should be treated as part of the ID design, not as a cosmetic label.

Collision risk for random-family UUIDs is usually estimated with a birthday-bound approximation. Version 4 has 122 effective random bits after the version and variant bits are fixed, so the rough probability for n generated values is:

p \approx \frac{n^{2}}{2 2^{122}}

That approximation explains why collisions are rare in normal application datasets, but it is not a substitute for storage constraints. Systems that cannot tolerate duplicate identifiers should still enforce uniqueness where the UUID is stored.

Privacy and Accuracy Notes:

Generated values, name and namespace inputs, details, anatomy rows, JSON, and history are produced in the browser session. Generation does not upload those values to a server, and the history is not a durable account or project store.

Use v4 when you want an opaque identifier with no embedded name or timestamp relationship.
Use v5 when repeatability matters, but remember that anyone with the same namespace and name can reproduce the same UUID.
Use v7 for broad time ordering, not for a guaranteed same-millisecond sequence.
A UUID is not a password, API key, session secret, or authorization proof.
Downloaded JSON, CSV, and DOCX records become files you manage outside the page.

Worked Examples:

Stable Domain Mapping:

Select Version 5 - SHA-1-name, keep Namespace as DNS, and enter example.com as Name. The UUID (canonical) value should be cfbff0d1-9375-5685-968c-48ce8b15ae17. Turning on Uppercase output changes UUID (formatted), but the canonical value remains the repeatable identifier.

Fresh Test Records:

Leave UUID version on Version 4 - Random and press Generate UUID several times. Each new UUID (canonical) should differ, and UUID History should list the latest generated entries with their version numbers for a quick test-data handoff.

Time-Friendly Event IDs:

Choose Version 7 - Unix time sortable for log or event records that benefit from rough chronological grouping. UUID Details should show v7 Unix time (UTC), v7 Unix time (local), and v7 Unix milliseconds. Treat same-millisecond ordering as random unless your application adds its own sequence.

Invalid Name-Based Setup:

If Version 5 is selected with name tenant-42 but namespace project-alpha, generation stays blocked because the namespace is not one of the accepted shortcuts or a UUID-shaped value. Replace it with DNS, URL, OID, X500, or a custom UUID namespace, then press Generate UUID again.

For v1 or v6 inspection, compare the decoded UTC and local time rows with the moment you generated the value. If those rows reveal more timing detail than your use case should expose, switch to v4 or v7.

FAQ:

Which UUID version should I choose?

Choose v4 for most fresh opaque IDs, v5 for repeatable namespace-and-name IDs, and v7 when broad creation-time ordering helps. Use v1, v3, or v6 mainly for compatibility or inspection needs.

Why did the displayed UUID change but the canonical UUID did not?

Uppercase output, Remove dashes, and Wrap in braces change UUID (formatted). Check UUID (canonical) when you need the underlying dashed lowercase value.

Why is the Generate UUID button disabled for v3 or v5?

Name-based versions require both a non-empty Name and a valid Namespace. Use DNS, URL, OID, X500, a 32-character hexadecimal namespace, or a UUID-shaped namespace.

Are v7 UUIDs strictly increasing?

No. The generated v7 values include Unix milliseconds plus random fields. Values created in different milliseconds usually group by time, but same-millisecond values are not forced into sequence here.

Can a UUID be used as a secret token?

No. UUIDs identify records. If possession of the string grants access, use a purpose-built secret token and normal authorization checks instead of relying on a UUID.

Is UUID History saved after reload?

No. UUID History is a current-session list capped at 20 entries. Copy or export the rows before refreshing if you need to keep them.

Glossary:

UUID: A 128-bit universally unique identifier represented in standard text form as 32 hexadecimal digits with optional dashes.
GUID: A common name for the same kind of identifier, especially in Microsoft and Windows contexts.
Canonical UUID: The standard dashed lowercase value before display-only formatting is applied.
Namespace: The UUID domain combined with a name to produce deterministic version 3 or version 5 output.
Variant: The layout-family bits that identify which broad UUID format the value follows.
Clock sequence: A time-based UUID field used to reduce duplicate risk around repeated or adjusted timestamps.
URN: A UUID written with the urn:uuid: prefix.
Node field: The final 48-bit field in time-based layouts, displayed here as node-like bytes when it can be decoded.

References:

RFC 9562: Universally Unique IDentifiers (UUIDs), Internet Engineering Task Force, May 2024.
Crypto.getRandomValues(), MDN Web Docs, last modified August 19, 2025.

Universally Unique Identifier (UUID) Generator

Latest UUID

Generated result

How to Use This Tool:

Interpreting Results:

Technical Details:

Structure and Rule Core:

Field Anatomy:

Privacy and Accuracy Notes:

Worked Examples:

Stable Domain Mapping:

Fresh Test Records:

Time-Friendly Event IDs:

Invalid Name-Based Setup:

FAQ:

Glossary:

References:

Universally Unique Identifier (UUID) Generator

Latest UUID

Generated result

Introduction:

How to Use This Tool:

Interpreting Results:

Technical Details:

Structure and Rule Core:

Field Anatomy:

Privacy and Accuracy Notes:

Worked Examples:

Stable Domain Mapping:

Fresh Test Records:

Time-Friendly Event IDs:

Invalid Name-Based Setup:

FAQ:

Glossary:

References: