Identifier workflow
UUID versions, encoded timestamps and privacy
A UUID is a 128-bit identifier, not encrypted evidence. Decoding describes its bit layout; it does not authenticate the source, prove uniqueness or establish when a real-world record was created.
Content updated: · Maintainer and corrections
Start with the variant, then the version
The variant determines how a UUID's remaining bits are interpreted. RFC 9562 uses the 10 bit prefix at bit positions 64–65; the version occupies bits 48–51. NCS (0), Microsoft (110) and reserved (111) layouts are recognized but not decoded as RFC versions. The visualizer uses network byte order, not a platform-specific binary GUID byte order.
Nil (all zero bits) and Max (all one bits) are special constants and are identified before variant or version interpretation. RFC variant versions 2, 0 and 9–15 are not decoded here. A structurally recognizable string is not proof of a genuine identifier or a safe access token.
v1 / v6 and v7 use different time units
v1 and v6 encode a 60-bit count of 100ns intervals since 1582-10-15 UTC. v6 rearranges the time fields; interpreting v1 bytes in v6 order produces a different time. The decoder preserves the full integer using BigInt and displays seven fractional UTC digits. Unix milliseconds are rounded down, including before the Unix epoch; use Unix 100ns ticks to retain sub-millisecond information.
v7 encodes 48-bit Unix milliseconds, displayed with three fractional UTC digits. Its other 74 bits are not necessarily all random: a generator may use counters or finer time fractions. v3 / v5 use name-based hashes, v4 uses random or pseudorandom bits, and v8 leaves application-specific choices. No generic timestamp or original name can be recovered from those layouts. Encoded time can be chosen or forged and does not prove record creation.
Keep normalization and batch errors explicit
Accept one canonical 8-4-4-4-12 UUID or 32 hex digits per line, plus a canonical UUID wrapped in braces or prefixed urn:uuid:. Hex and the URN prefix are case-insensitive. Only outer ASCII spaces and tabs are removed. Nested wrappers, Unicode whitespace, hidden characters and misplaced hyphens are rejected rather than repaired.
The whole input is limited to 128 KiB UTF-8 and 1,000 non-blank lines. Exceeding either limit rejects the whole batch; rows are never silently truncated. Blank lines are skipped but counted, physical line numbers and duplicates are retained, and invalid rows remain in the downloaded report. The list and report preview show at most 50 rows at a time; the download includes every processed row. Modern browsers with BigInt are required. No approximate fallback is used.
Identifiers can still reveal or link private data
v1 / v6 expose time, a clock sequence and a node value. Node bits alone cannot prove a real MAC address, manufacturer or device; displaying the multicast bit does not establish provenance. v7 exposes encoded time, and any stable UUID may link records across logs and services. UUIDs are not anonymization or authorization.
The tool processes inputs in page memory without uploading, persisting or placing identifiers in the URL or input analytics. Clipboard operations and file downloads happen only when requested. The JSON report contains original lines and decoded values, including errors: review it before sharing. Clearing removes the page's current results; it cannot erase a downloaded file, system clipboard or browser-managed history. Use disposable examples for sensitive systems.
RFC 9562 Appendix A examples (same encoded second):
v1: c232ab00-9414-11ec-b3c8-9f6bdeced846
v6: 1ec9414c-232a-6b00-b3c8-9f6bdeced846
v7: 017f22e2-79b0-7cc3-98c4-dc0c0c07398f
UTC: 2022-02-22T19:22:22Z
v6 ending time field 6b01 preserves:
2022-02-22T19:22:22.0000001ZData provenance