Generate UUID v6

A 128-bit identifier carrying the same v1 timestamp, clock, and node fields, but reordered so the high bits of the timestamp lead — making the ID byte-sortable in databases.

Browser extensions can read all data on this page. Use a private/incognito window with extensions disabled.

Generated · 0 IDs

This ID

Length 36 chars

Bits 128 (timestamp first, then random)

Collision risk negligible

Features

Time-sortable

Watch out

Embeds generator fingerprint

Collision

1% collision chance after ≈ 215,288,163 generators in one 100 ns tick

Random part 61 random bits

Counted together Separate generators in one 100 ns tick

Built-in guard One generator advances the timestamp before repeating

UUID v6 has the same collision profile as v1, just reordered for sorting. One generator stays distinct by moving the timestamp forward; separate generators also need matching randomized node and clock-sequence bits.

Validate and parse UUID v6

Paste an ID

Paste UUID v6

About UUID v6

Use when: you have a v1 deployment and want byte-sortable IDs without changing the field layout. v6 simply reorders v1 so the high bits of the timestamp come first.

Avoid when: you are starting from scratch. RFC 9562 recommends v7 over v6 for new systems.

How it is generated

A v6 UUID is v1 with the timestamp pieces reordered so the high bits come first. Same fields, same Gregorian 100-ns time source — but now the binary representation sorts in creation order.

Think of it as a drop-in for v1 deployments that need their UUIDs to behave like database keys. RFC 9562 recommends v7 over v6 for new systems; v6 is mostly there for v1 migration paths.

01 Read the same 60-bit Gregorian 100-ns timestamp you would for v1, with the monotonic guard applied.
02 Slice it into time_high (top 32 bits), time_mid (next 16 bits), and time_low (low 12 bits).
03 Write time_high to bytes 0–3, time_mid to bytes 4–5, time_low into the low nibble of byte 6 and all of byte 7 (12 bits).
04 Write the 14-bit clock sequence into bytes 8–9 and the 48-bit node into bytes 10–15.
05 Overwrite the high nibble of byte 6 with 0110 (version 6) and the top two bits of byte 8 with 10 (variant).
06 Hex-encode with dashes after bytes 4, 6, 8, 10.

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
└──┬───┘ └─┬┘ └─┬┘ └─┬┘ └────┬─────┘
   │       │    │    │       └── 48-bit node
   │       │    │    └────────── 14-bit clock_seq (N = top 2 bits = variant "10")
   │       │    └─────────────── version "6" + low 12 bits of timestamp
   │       └──────────────────── timestamp middle 16 bits
   └────────────────────────── timestamp high 32 bits (leads — bytes sort!)

All of this runs in your browser. Random bytes come from crypto.getRandomValues, timestamps come from the system clock, and nothing about the generated ID leaves the tab.