UUID v6 Generator

UUID v6 is "v1 with the timestamp bits reordered to be sortable." It exists for migrating from v1; for new code, use v7.

The problem v6 solves

UUID v1 encodes a 60-bit timestamp, but in three reordered chunks: time_low first, then time_mid, then time_hi_and_version. Lexicographic sort on the resulting string does not produce chronological order, which makes v1 UUIDs poor primary keys for time-series data.

v6 fixes this by reading the timestamp bits in their natural most-significant-first order. Same 1582 epoch, same 100-nanosecond precision, same node ID layout — just sortable.

Bit layout

v1: time_low(32) | time_mid(16) | ver|time_hi(12) | var|seq(14) | node(48)
v6: time_hi(48)  | time_mid(12) | ver           | time_lo(12)| var|seq + node

v6 vs v7

When v6 makes sense

The main scenario: you have an existing system on v1 UUIDs and want to introduce sortability without changing what the timestamp means. v6 lets you keep the same 1582-epoch / 100ns-precision interpretation — every existing v1 timestamp parser still works on the timestamp portion of v6 (after byte reordering).

For literally any other case — green-field projects, new tables, new services — pick v7.

Generating v6

The npm uuid package this site uses does not yet support v6, so the generator above produces v1 by default — the closest available cousin. To produce v6 in your code:

// Java (uuid-creator)
import com.github.f4b6a3.uuid.UuidCreator;
UuidCreator.getTimeOrdered();             // v6

// Go (gofrs/uuid)
import "github.com/gofrs/uuid/v5"
v6, _ := uuid.NewV6()

// Rust (uuid crate with v6 feature)
use uuid::{Uuid, ContextV7};
let v6 = Uuid::now_v6(&context, node_id);

Decoding a v6 timestamp

Same epoch and precision as v1 — see the v1 page's decode example. The only difference is the byte order: with v6, you concatenate the first three groups in natural order (no reshuffling). The validator handles both automatically.