Universally Unique Identifier (UUID) Generator

Introduction

A UUID is a 128-bit identifier built so records can be labeled without a single central counter. The hard part is rarely producing a string. The real choice is deciding whether you need a fresh random value, the same value every time for the same name, or a value whose leading bytes reflect when it was created.

This generator covers all of the common branches in one place: version 1, 3, 4, 5, 6, and 7. It shows the latest UUID in a copy-ready summary, keeps the canonical form alongside alternate text formats, exposes the version and variant bits, exports the current details or recent history, and lets you inspect extra version 1 fields instead of treating every UUID as an unreadable blob.

For most application work, version 4 and version 7 are the two practical starting points. Version 4 gives you a fresh random identifier each time. Version 7 keeps a Unix-millisecond timestamp at the front and fills the rest with randomness, so newer values usually group later when sorted as raw bytes. Version 3 and version 5 are different: they are name-based, so the same namespace and the same name produce the same canonical UUID again.

This page also makes the less obvious parts visible. You can remove dashes, switch to uppercase, wrap the text in braces, copy the canonical form or the displayed form, and inspect a short recent history. That is useful for tests and integration notes, but it also exposes tradeoffs that matter in real systems: version 1 can reveal time and node details, version 3 and version 5 are predictable when the inputs are known, and version 7 in this build is time-ordered rather than strictly monotonic within the same millisecond.

Technical Details

UUID rules are now defined by RFC 9562. Every UUID is still 128 bits, but a few bits are reserved to mark the version and the variant, so the version you choose changes how the remaining bits are filled. In this generator, versions 1, 3, 4, and 5 come from the loaded UUID library, version 6 is built by generating a version 1 UUID and rewriting the timestamp into a version 6 layout, and version 7 is assembled in the browser from the current Unix time in milliseconds plus random bytes from the browser cryptography API.

Name-based UUIDs are driven by the combination of a namespace and a name string. This page accepts the standard namespace keywords DNS, URL, OID, and X500, and it also accepts a custom namespace as either 32 hex characters or a dashed UUID. Version 3 uses MD5 and version 5 uses SHA-1 because that is how those two UUID versions are defined. The point of either one is repeatability, not secrecy.

Formula Core

The generator supports three main patterns: deterministic name-based output, fresh random output, and time-led output.

The variant field tells you which broad UUID layout family the value belongs to. For values generated on this page, that badge will normally read RFC 4122, because the code labels the standard variant bits that way. The version field then tells you which generation family was used.

Version 1 deserves special attention because this page decodes more than the string itself. The metrics table exposes the UTC timestamp, the local timestamp rendered by your device, the clock sequence, the final six node bytes, and whether the node appears locally administered or looks like a universally unique MAC-based value. That is useful for inspection, but it is also a reminder that version 1 is not an opaque random identifier.

Version 7 is the most modern time-friendly option offered here, but it is still worth reading carefully. RFC 9562 describes version 7 as a Unix Epoch millisecond layout with random fields around it, and it allows extra monotonic techniques when an implementation wants them. This page does not add such a counter. It uses the current millisecond plus randomness, so sorting usually follows time across different milliseconds, while values created inside the same millisecond may appear in either order.

Everyday Use & Decision Guide

If you only need a fresh ID for a record, test fixture, or one-off reference, start with version 4. It asks for no extra inputs and gives you a clean random UUID. If you expect to sort large batches by creation time and want newer values to cluster later in raw-byte order, move to version 7. That gives you time-led ordering without the explicit node details that version 1 can expose.

Use version 5 when the same real-world name should always map to the same UUID inside the same namespace. A common example is turning a domain name, URL, or internal object path into a stable derived ID for imports or repeatable fixtures. Use version 3 only when you specifically need version 3 compatibility, because the practical difference on this page is not the workflow but the UUID family you are matching.

Choose version 1 when you need to inspect classic time-based UUID parts directly. Choose version 6 when you need a time-based UUID that sorts more naturally than version 1 but you still want to stay in that lineage. In this generator, version 6 is created by reordering a version 1 timestamp, so it inherits the time-based family behavior even though the page does not decode version 6 fields into separate metrics rows.

One page-specific behavior matters before you rely on the output. The generator refreshes automatically when you change parameters. For version 3 and version 5, the canonical UUID stays the same when the namespace and name stay the same, so uppercase, braces, or dash removal only change how the text is displayed. For version 1, 4, 6, and 7, the same formatting change creates a new UUID because the page generates a fresh value after the option change.

The short history is best treated as a working scratchpad. It keeps the latest 20 generated entries for the current page state, along with the version, variant, local timestamp, and an option summary. That is enough for comparing a batch of generated values or exporting a quick record, but it is not durable storage. Reloading the page clears it.

Step-by-Step Guide

1. Pick the UUID family first. Use v4 for a fresh random ID, v5 for a stable namespace-plus-name mapping, v7 for time-led ordering, and v1 or v6 only when that time-based lineage is the actual goal.
2. If you selected v3 or v5, enter a name and a valid namespace. The page accepts DNS, URL, OID, X500, a 32-character hex namespace, or a dashed UUID namespace.
3. Use the Advanced panel only for text formatting needs such as uppercase output, no dashes, or braces. Remember that changing these options regenerates a fresh value for non-deterministic versions.
4. Read the summary box first, then open UUID Metrics to compare the formatted UUID, canonical UUID, URN, version, variant, and extra version 1 fields when they are available.
5. Open History if you need a short run of recent values, or open JSON if you want the current inputs, UUID details, optional version 1 decode, and history in one copy-ready object.
6. Copy the current value, export the metrics or history as CSV or DOCX, or download the JSON snapshot before leaving the page if you need a record.

Interpreting Results

The most important output split is between the canonical UUID and the displayed UUID. The canonical value is the dashed lowercase base string generated by the current version. The displayed value may remove dashes, switch to uppercase, or add braces. If a downstream system asks for one exact format, copy that exact row rather than editing the text by hand.

Version 1 rows deserve a slower read. The UTC and local time tell you when the UUID was generated. The clock sequence helps distinguish values around repeated or closely spaced timestamps. The node row shows the last six bytes of the UUID, and the node type badge warns whether those bytes look locally administered or MAC-derived. If you do not want those signals in the identifier itself, switch away from version 1.

Version 6 and version 7 are better read as ordering tools than as decoding tools. Version 6 keeps time structure in a layout that sorts more naturally than version 1. Version 7 starts with Unix milliseconds and then adds randomness. That usually makes it a better default when you want chronological grouping but do not need to expose version 1 fields directly.

The history tab is especially useful when you are comparing versions. A run of version 5 entries with the same namespace and name should keep repeating the same canonical UUID. A run of version 4 or version 7 entries should keep changing. If the page is not behaving that way, check whether you changed the version, the namespace, the name, or only the display toggles.

Worked Examples

1. Stable domain mapping with version 5

   Select v5, enter DNS as the namespace, and use example.com as the name. The generator returns the same canonical UUID every time you reuse that exact pair.

   This is useful for repeatable fixtures, import previews, or any workflow where the same real-world label should map back to the same derived ID.

2. Fresh test records with version 4

   Leave the page on v4 and press Generate several times. Each entry in History is a fresh identifier, and the history export gives you a quick CSV or DOCX record of what was generated in that session.

   That fits seed data, issue repro notes, or QA runs where you want several independent IDs without carrying meaning inside them.

3. Time-led event IDs with version 7

   Switch to v7 when you want event identifiers that tend to group in creation order when sorted. Values created across different milliseconds should usually sort later as time moves forward.

   Use that benefit as chronological grouping, not as exact sequencing. This page does not add a counter for same-millisecond generations, so two values created very close together can still swap order when compared.

4. Inspecting exposure with version 1

   Generate a v1 UUID and open UUID Metrics. The page shows when it was created, what clock sequence it used, and what the node bytes look like.

   That makes version 1 useful for debugging or teaching, but it also shows why many modern systems prefer version 4 or version 7 when they do not want time and host-related structure visible in the identifier.

FAQ

Glossary

Canonical UUID

The base dashed UUID string that the page treats as the current generated value.

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 version 1 field used to help distinguish values around repeated or closely spaced timestamps.

URN

A UUID written with the urn:uuid: prefix instead of as a bare string.

Time-ordered UUID

A UUID family such as version 6 or version 7 whose leading bits reflect generation time more clearly than version 4.

References

• RFC 9562: Universally Unique IDentifiers (UUIDs)
• Crypto.getRandomValues(), MDN Web Docs