Generate UUID v1

A 128-bit identifier built from a 60-bit Gregorian-epoch timestamp (in 100-nanosecond ticks), a 14-bit clock sequence, and a 48-bit node field that historically held the generator’s MAC address.

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 (60 timestamp · 14 clock · 48 node)

Collision risk low

Watch out

Embeds generator fingerprint Legacy

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

The timestamp normally keeps v1 IDs apart. A collision needs two separate generators to land in the same 100-nanosecond tick and reuse the same randomized node and clock sequence.

Validate and parse UUID v1

Paste an ID

Paste UUID v1

About UUID v1

Use when: a legacy system requires the original Gregorian-time UUID format defined in RFC 9562 §5.1.

Avoid when: you care about privacy. The node field traditionally contained a MAC address, and the timestamp reveals when the ID was created.

How it is generated

A v1 UUID is 16 bytes rendered as 32 lowercase hex characters in the familiar 8-4-4-4-12 dash layout.

The ID packs three things: a 60-bit timestamp counted in 100-nanosecond ticks from 1582-10-15 (the Gregorian reform date), a 14-bit clock sequence that stays stable within a batch (re-randomized on each Regenerate), and a 48-bit node identifier that historically held the host MAC.

The quirk is that the timestamp is sliced into low, middle, and high pieces that are not stored in sort order, which is why v1 is not byte-sortable.

01 Read Date.now(), add the offset to the 1582 UUID epoch, and multiply by 10,000 to convert ms to 100-ns ticks. Bump by 1 tick if the result is not strictly greater than the previous one (monotonic guard).
02 Split that 60-bit number into time_low (low 32 bits), time_mid (next 16 bits), and time_hi (top 12 bits).
03 Write time_low to bytes 0–3, time_mid to bytes 4–5, time_hi to bytes 6–7 (all big-endian).
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 0001 (version 1) and the top two bits of byte 8 with 10 (the variant "10" specified in RFC 9562 §4.1; same variant the obsoleted RFC 4122 defined).
06 Hex-encode and insert dashes after bytes 4, 6, 8, 10.

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
└──┬───┘ └─┬┘ └─┬┘ └─┬┘ └────┬─────┘
   │       │    │    │       └── 48-bit node (random multicast in this impl)
   │       │    │    └────────── 14-bit clock_seq (N = top 2 bits = variant "10")
   │       │    └─────────────── time_hi + version (M = high nibble = "1")
   │       └──────────────────── time_mid (16 bits)
   └────────────────────────── time_low (32 bits)

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.