Generate UUID v7

A 128-bit identifier that puts a 48-bit Unix-millisecond timestamp at the front followed by a monotonic counter and 62 random bits — the modern default for time-sortable IDs.

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 (48 Unix-ms · 12 counter · 62 random)

Collision risk negligible

Features

Time-sortable

Collision

1% collision chance after ≈ 304,463,440 independent generators in one millisecond

Random part 62 random bits

Counted together Independent generators in one millisecond

Built-in guard 4,096 IDs per millisecond per generator

Within one generator the 12-bit counter keeps IDs distinct inside a millisecond. Across independent generators in the same millisecond, a collision also needs the random counter position and the 62 random payload bits to match.

Validate and parse UUID v7

Paste an ID

Paste UUID v7

About UUID v7

Use when: almost any new project. v7 combines a Unix-millisecond timestamp with strong randomness, giving you database-friendly time ordering and unguessability in one ID. RFC 9562 explicitly recommends it as the modern default.

Avoid when: you need a deterministic ID derived from data (use v5) or you want to keep the creation time private (use v4).

How it is generated

A v7 UUID is the modern default. The first 48 bits are a Unix-millisecond timestamp that leads the binary form, so v7s sort by creation time in any database column. The remaining space is split between a 12-bit same-millisecond counter and 62 random bits.

This implementation uses RFC 9562 §6.2 Method 1 (Fixed-Length Dedicated Counters): rand_a (12 bits) is treated as a counter that increments on same-ms calls and reseeds from randomness each new millisecond. That keeps two v7s minted in the same millisecond strictly ordered.

The collision estimate on this page counts only the 62 random bits, not the 12-bit counter. Within one generator the counter simply increments, but across independent generators in the same millisecond it is seeded from randomness too, so the real space guarding against an accidental match is 74 bits wide. Counting only the 62 bits we can always vouch for keeps the estimate deliberately conservative: the true threshold sits roughly 64 times further out than the figure shown.

01 Read Date.now(). If the clock went backwards, clamp it to the previous timestamp.
02 If this millisecond matches the previous one, increment the 12-bit counter; if the counter overflows, bump the timestamp by 1 ms. Otherwise reseed the counter from randomness.
03 Write the 48-bit timestamp big-endian into bytes 0–5.
04 Fill bytes 6–15 with random bytes from crypto.getRandomValues.
05 Overwrite the low nibble of byte 6 and all of byte 7 with the 12-bit counter (rand_a).
06 Overwrite the high nibble of byte 6 with 0111 (version 7) and the top two bits of byte 8 with 10 (variant). Bytes 8–15 minus those two bits stay random (rand_b, 62 bits).
07 Hex-encode with dashes after bytes 4, 6, 8, 10.

xxxxxxxx-xxxx-7xxx-Nxxx-xxxxxxxxxxxx
└─────┬─────┘ └─┬┘ └─┬┘ └────┬─────┘
      │         │    │       └── rand_b continued (48 bits, bytes 10..15)
      │         │    └────────── variant "10" (top 2 bits of byte 8) + 14 bits of rand_b
      │         └─────────────── version "7" (top nibble of byte 6) + rand_a (low 12 bits of bytes 6..7, used as counter)
      └─────────────────────── 48-bit Unix-ms timestamp (bytes 0..5)

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.