Universally Unique Identifier (UUID) Generator

Introduction

A UUID is a 128-bit identifier meant to label records without requiring a central counter. That broad idea sounds simple, but the version you choose changes the character of the identifier: some UUIDs are random, some are deterministic for the same input, and some are shaped so newer values tend to sort closer together in time.

This generator supports versions 1, 3, 4, 5, 6, and 7, then shows the result in both canonical and convenience formats. You can copy the latest value directly from the summary box, inspect detailed metrics such as version and variant, export the current state as CSV, DOCX, or JSON, and review a short generation history instead of losing each previous value as soon as a new one appears.

The most practical split is between deterministic and non-deterministic versions. Versions 3 and 5 combine a name with a namespace so the same inputs always yield the same UUID. Versions 1, 4, 6, and 7 produce fresh values each time you generate them. That makes the package useful for both repeatable mappings, such as turning the same domain name into the same stable identifier, and for issuing new IDs for test data, logs, or application records.

The bundle also exposes differences that are often hidden. Version 1 gets decoded into UTC time, local time, clock sequence, node bytes, and node type. Versions 6 and 7 cover the newer time-ordered families. Formatting options let you remove dashes, switch to uppercase, or wrap the result in braces, while the metrics table still keeps the canonical text, a URN form, and copy-friendly variants close at hand.

UUIDs are often treated as opaque strings, but they are not all equally private or equally suitable for every job. Time-based families can reveal timing structure, name-based families are predictable when inputs are known, and this package regenerates values when parameters change. Those are useful properties when you choose them on purpose, but they matter enough to understand before you paste a value into production data or public logs.

Everyday Use & Decision Guide

Start by picking the version for the job rather than by picking the newest number. Version 4 is the general-purpose choice when you want a fresh identifier with no meaning encoded in it. Versions 3 and 5 are better when you need repeatability from the same name and namespace. Version 7 is attractive when you want identifiers that cluster by generation time more naturally than version 4. Versions 1 and 6 are mainly useful when compatibility with time-derived UUID families matters.

If you choose version 3 or 5, you also need a name and a namespace. The namespace field accepts the standard DNS, URL, OID, and X500 keywords, a 32-hex value that the package reformats into canonical UUID form, or a 36-character UUID-shaped namespace string. That means you can use the well-known namespace constants or supply your own namespace identifier when you need a private naming domain.

One package-specific behavior is worth noticing before you rely on the history tab. Parameter changes trigger regeneration after a short delay. For deterministic versions, the canonical UUID stays the same when the name and namespace stay the same, so formatting changes mainly alter presentation. For versions 1, 4, 6, and 7, the same formatting change creates a fresh UUID because generation runs again. The history list therefore captures a sequence of outputs, not a single fixed UUID viewed through different skins.

That history is intentionally lightweight. It keeps the most recent 20 generated entries in the current page session, along with version, variant, local timestamp, and option summary, and it can be copied or exported. It is useful for comparing a short run of generated values or keeping a working set during tests, but it is not permanent storage and it is not a registry.

Technical Details

Modern UUID guidance is defined in RFC 9562, which updates the older RFC 4122 family and formally describes versions 6 and 7. The package follows that broader UUID model while mixing two implementation paths. Versions 1, 3, 4, and 5 come from the bundled UUID library. Version 6 is assembled locally by taking a version 1 UUID, reconstructing its timestamp, and rewriting the bytes into the version 6 layout. Version 7 is assembled locally from the current Unix time in milliseconds plus random bytes from the browser cryptography API.

Name-based versions work by hashing namespace bytes together with the UTF-8 bytes of the name. Version 3 uses MD5. Version 5 uses SHA-1. The important property is determinism, not secrecy: the same namespace and the same name always produce the same UUID. That is useful for repeatable keys and stable derived IDs, but it also means these versions should not be treated as secret-bearing tokens or as a way to hide sensitive names.

Version 1 carries a 60-bit timestamp measured in 100-nanosecond intervals from the Gregorian UUID epoch, plus a clock sequence and a node field. This package decodes those pieces and shows them directly in the metrics table, which makes version 1 a good teaching or debugging choice when you want to inspect the structure rather than merely emit a string. Version 6 keeps the same time-based lineage but moves the timestamp to the front so lexical order better reflects generation time.

Version 7 uses the first 48 bits for Unix milliseconds and fills the remaining non-version, non-variant bits with randomness. That makes it a strong practical choice when you want values that group by time without inheriting the exact structure of version 1. In this package, version 7 does not add a sub-millisecond counter or monotonic sequence step, so identifiers created within the same millisecond are not guaranteed to preserve strict generation order when sorted.

Formatting is handled as a view layer on top of the canonical UUID string, with three toggles: uppercase, no dashes, and braces. The metrics view keeps both canonical and convenience forms visible so you can copy the exact representation a downstream system expects. The URN row is helpful for standards-aware integrations that want the urn:uuid: prefix instead of the raw 36-character canonical text.

Export behavior is broader than the title suggests. The metrics table can be copied or downloaded as CSV and exported as DOCX. The history list has its own CSV and DOCX export path. The JSON tab can be copied or downloaded directly. Combined with the session history, that makes the generator useful not only for producing a UUID but also for documenting how a given value was produced during a test or integration review.

Step-by-Step Guide

1. Choose the UUID version that matches your need: deterministic mapping, random identifier, or time-ordered identifier.
2. If you selected version 3 or 5, enter the name and a namespace keyword or namespace UUID value.
3. Use the formatting toggles if you need uppercase text, brace wrapping, or output without dashes for a target system.
4. Generate the value and review the summary badges plus the metrics table for canonical form, URN, version, and variant details.
5. Copy the current value, export the details, or inspect the history and JSON tabs if you need a fuller audit trail for the current session.

Interpreting Results

The most important distinction is between canonical and formatted output. The canonical UUID is the standard lowercase hex-and-dash representation. The formatted output may remove dashes, switch to uppercase, or add braces. Those view options can be necessary for compatibility, but the metrics view makes it clear which exact forms are available so you do not have to transform them by hand.

For version 1, the extra decoded fields matter as much as the string itself. UTC and local timestamps tell you when the UUID was generated, the clock sequence helps distinguish repeated time values, and the node information shows whether the final six bytes look like a locally administered identifier or a universally unique MAC-derived value. That visibility is useful for inspection, but it is also a reminder that version 1 is not an opaque random token.

For versions 6 and 7, the practical reading is about ordering rather than decode. They are better thought of as time-ordered families than as secret-bearing values. Version 6 inherits time structure from version 1. Version 7 uses Unix-millisecond time plus randomness. Both can improve sort behavior relative to version 4, but only version 3 and version 5 offer the same output every time for the same input.

Worked Examples

A stable naming example fits version 5 well. Suppose you want every appearance of the same domain name to map to the same UUID in a test fixture. Choose version 5, enter the DNS namespace, then provide the domain string as the name. Every time you reuse that same pair, the canonical UUID stays the same, which is useful for reproducible datasets and idempotent imports.

A general application-record example fits version 4. Each press of Generate produces a fresh identifier with no name input required. If you then toggle uppercase or dash removal, the package will regenerate the UUID because the parameters changed, so treat the new value as a new identifier rather than as a restyled copy of the original one.

A time-ordered example fits version 7. If you are producing event IDs or queued work items and want newer entries to cluster later when sorted, version 7 is a strong choice. The identifiers still include randomness, and in this package two values created inside the same millisecond are not forced into strict monotonic order, so the benefit is chronological grouping rather than perfect sequencing.

FAQ

Which version should I choose most of the time?

Choose version 4 for fresh general-purpose IDs, version 5 when repeatable name-to-ID mapping matters, and version 7 when you want timestamp-first UUIDs for newer application designs. Use versions 1 or 6 mainly when you have a compatibility reason to stay in the time-based families.

Do versions 3 and 5 protect the input name?

No. Their purpose is deterministic mapping, not secrecy. If the namespace and name are known, the output can be reproduced. They are helpful for stable identifiers, not for hiding sensitive values.

Does changing uppercase, braces, or dashes always keep the same UUID?

Only for deterministic versions with unchanged name and namespace. In this package, parameter changes regenerate the current value, so non-deterministic versions produce a new UUID when those toggles change.

Is the history permanent?

No. The history list is a session-level convenience with a cap of 20 entries. Export or copy the data if you need to keep it beyond the current page state.

Are version 7 UUIDs strictly increasing?

Not in this bundle. They are built from Unix milliseconds plus random bits, so sorting generally reflects time, but values generated inside the same millisecond are not forced into exact creation order.

Glossary

References

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