UUID パーサー
UUID v1 / v3 / v4 / v5 / v6 / v7 / v8 を解析・検証し、タイムスタンプ(v1 / v6 / v7)、variant、バイト構造まで分解表示します。
AK
appkiro.comPaste one or more UUIDs (one per line).
Showing 7 of 7 results
Selected:
550e8400-e29b-41d4-a716-446655440000UUID Breakdown
Binary (Hex)
55 0e 84 00 e2 9b 41 d4 a7 16 44 66 55 44 00 00Binary
01010101 00001110 10000100 0000000011100010 10011011 01000001 1101010010100111 00010110 01000100 0110011001010101 01000100 00000000 00000000[
{
"uuid": "550e8400-e29b-41d4-a716-446655440000",
"version": 4,
"variant": "RFC 4122",
"valid": true
},
{
"uuid": "6ba7b814-9dad-11d1-80b4-00c04fd430c8",
"version": 1,
"variant": "RFC 4122",
"valid": true,
"timestamp": "1998-02-04 22:13:53.151Z",
"unixMs": 886630433151
},
{
"uuid": "12d3c0f3-9c9d-11ee-be56-0242ac120002",
"version": 1,
"variant": "RFC 4122",
"valid": true,
"timestamp": "2023-12-17 05:28:13.472Z",
"unixMs": 1702790893472
},
{
"uuid": "01890f2d-3c80-7b11-b3e0-6b8f84b3a2d0",
"version": 7,
"variant": "RFC 4122",
"valid": true,
"timestamp": "2023-07-01 01:59:30.176Z",
"unixMs": 1688176770176
},
{
"uuid": "4f7e5b6c-9a1d-5c4b-8b6a-9b1c2e3d4f5a",
"version": 5,
"variant": "RFC 4122",
"valid": true
},
{
"uuid": "0190b9d0-d5cc-7f7e-b2e4-0c1d2e3f4a5b",
"version": 7,
"variant": "RFC 4122",
"valid": true,
"timestamp": "2024-07-16 04:33:09.580Z",
"unixMs": 1721104389580
},
{
"uuid": "3d813cbb-47fb-32ba-91df-831e1593ac29",
"version": 3,
"variant": "RFC 4122",
"valid": true
}
]UUID Parser reads any list of UUIDs you paste in, recognises the format, and explains what each value contains. It works on the canonical 8-4-4-4-12 hex form used across databases, message queues, log files, and HTTP headers, and it understands every version from v1 through v8 defined in RFC 4122 and the newer RFC 9562. The page is a single static client component, so the work happens on your machine and nothing is uploaded.
Most teams reach for a tool like this when something is broken. A row is missing, a foreign key looks wrong, two services disagree on which event came first, or a piece of code is generating values that another service refuses to accept. Pasting the identifiers in question into a parser is the fastest way to confirm the version, variant, and — for time-bearing versions — the moment the value was minted.
Splits each UUID into its five canonical groups, identifies the version digit and variant bits, decodes the timestamp for v1, v6, and v7, and shows the byte and binary layout for the value you select in the table.
Backend engineers triaging stale rows, data analysts cleaning up exports, support agents matching customer records to log lines, and security reviewers checking whether a UUID accidentally exposes timing or device information.
Use it before opening an incident ticket, while writing a migration that touches identifier columns, when reproducing a bug from production logs, or whenever a third-party API rejects an identifier and you need to know whether the value is even a valid UUID.
Inputs never leave the browser. Validation, decoding, deduplication, and export generation all run in JavaScript loaded by this page. Closing the tab is enough to drop the data — there is no cache on a server somewhere to clean up.
Different versions encode different things. Reading a v1 timestamp tells you when a row was inserted. Spotting a v4 means the value carries no creation time. The parser exposes those distinctions so a quick glance answers questions that would otherwise need a database round-trip.
The table on the left lists every detected value with its version, variant, and validity. Click any row to populate the details panel on the right with the decoded fields, byte breakdown, hex stream, and binary view of that single UUID.
v1Time + node
60-bit timestamp counted in 100-nanosecond ticks since 1582, joined with a 14-bit clock sequence and a 48-bit node — historically the host MAC address.
v3MD5 namespace
Deterministic identifier produced by hashing a namespace UUID together with a name. Same inputs always return the same UUID, which makes v3 useful for stable mappings.
v4Random
122 bits of random data with the version and variant bits set. The default choice for general-purpose primary keys when ordering does not matter.
v5SHA-1 namespace
Same idea as v3 but truncates a SHA-1 hash instead of MD5. Preferred over v3 when stronger collision resistance is wanted.
v6Reordered time
v1 with the timestamp bytes rearranged so that lexical order matches chronological order. Easier to use as a database index than v1.
v7Unix-ms time-ordered
Leading 48 bits hold a Unix millisecond timestamp followed by random bits. Sorts naturally by creation time and is the preferred replacement for v1 in new systems.
v8Custom layout
Reserved for application-defined formats. The version and variant bits are still set, but the rest of the layout is decided by the system that produced the value.
Every UUID is sixteen bytes laid out as four-two-two-two-six. The first three groups store version-specific data, the fourth group carries the variant bits in its leading nibble, and the final group is the node or random tail. The parser colours each group in the breakdown panel so the version digit (the first hex character of the third group) and the variant nibble (the first hex character of the fourth group) are easy to verify by eye.
For new tables and new APIs, v7 is usually the strongest default. The leading Unix-millisecond bytes mean primary-key inserts cluster at the end of the index instead of scattering across pages, which improves write throughput on large tables. v4 still works well for cases where ordering is irrelevant and a stable random key is enough. Avoid v1 when the host's MAC address should not be exposed, and avoid v3 unless a deterministic mapping is genuinely required.
A UUID can carry more information than it appears to. v1 leaks the device that generated it through the node field, and any time-bearing version reveals when the value was minted. If those signals are sensitive in your context, prefer v4 or use v7 with the awareness that the timestamp is recoverable from the bytes.
A UUID is a 128-bit identifier written as 32 hexadecimal characters in the 8-4-4-4-12 layout. Teams use UUIDs to label rows, files, sessions, and events without coordinating with a central authority, because the chance of accidentally generating the same value twice is vanishingly small.
The parser handles every version defined in RFC 4122 and RFC 9562: v1 time-and-node, v3 MD5 namespace, v4 random, v5 SHA-1 namespace, v6 reordered time, v7 Unix-millisecond time-ordered, and v8 custom. Each version has a different layout, so the breakdown panel adapts to whichever value is selected.
No. The page runs the parsing, validation, breakdown, and export steps inside your browser. Identifiers stay on your device, which is helpful when the values came from production logs, internal tickets, or anything you would not want to paste into a third-party form.
v1 and v6 carry a 60-bit count of 100-nanosecond intervals since 15 October 1582. The parser shifts those bits back into a single number, subtracts the Gregorian epoch offset, and converts to Unix milliseconds. v7 already stores a 48-bit Unix-millisecond timestamp in the leading bytes, so the conversion is a direct read.
The variant signals which specification produced the UUID. The first hex digit of the fourth group encodes the variant bits. RFC 4122 values start with 8, 9, a, or b. NCS legacy values start with 0–7. Microsoft GUIDs use c or d, and the remaining range is reserved for future use.
For v1, v6, and v7 you can read the embedded timestamp directly. For v3, v4, v5, and v8 the time of creation is not stored, so external context — a database row, a log line, a filename — is the only way to know when the value appeared.
v1 includes the host MAC address (or a stable substitute) in the node field, and the timestamp resolves down to fractions of a microsecond. That combination can identify the machine and the moment the value was minted. v4 has no timestamp, and v7 has a millisecond timestamp without any device fingerprint.
v4 is still a strong choice when sortability does not matter and you want the simplest model: random bits with version and variant flags. v7 is preferable when records are inserted into a database index or log, because the leading bytes are time-ordered and adjacent inserts cluster together.
The row stays in the table with an Invalid status, the version column is blank, and the breakdown panel hides version-specific fields. The summary card on the left counts invalid entries so a malformed value does not silently disappear from a paste.
Every valid UUID is normalised to lowercase canonical form before comparison, so case differences do not produce false duplicates. The Unique card shows distinct values, and the Duplicate card shows how many of the valid inputs collide with an earlier line.