UUIDv7 Generator and UUID / ULID Decoder

Generate a batch of UUIDv7 or ULID identifiers, or paste an existing identifier to inspect its timestamp and format.

How it works

UUIDv7 stores Unix milliseconds in its first 48 bits, followed by version and variant bits and 74 random bits (RFC 9562 section 5.7). ULID combines a 48-bit millisecond timestamp with 80 random bits and encodes it in Crockford base32. This generator uses crypto.getRandomValues and limits each batch to 1,000 identifiers.

Random identifiers created within the same millisecond are not guaranteed to sort in generation order. Clock rollback is not corrected. UUIDv1 and UUIDv6 use Gregorian-epoch ticks; decoded Unix nanoseconds preserve their tick precision, while the displayed date floors to milliseconds. UUIDv7 and ULID milliseconds need no rounding. Other UUID versions have no timestamp decoded here.

Worked examples

RFC UUIDv7 test vector

017f22e2-79b0-7cc3-98c4-dc0c0c07398f contains 1645557742000 Unix milliseconds: 2022-02-22T19:22:22.000Z.

Zero timestamp ULID

00000000000000000000000000 contains timestamp 0: 1970-01-01T00:00:00.000Z.

Frequently asked questions

Are collisions impossible?

No. Randomness makes collisions unlikely, but systems that require uniqueness should enforce it in storage.

Are these secrets?

Do not use time-bearing identifiers as authentication secrets. They disclose their timestamp.

Which UUIDs can I decode?

Canonical UUID strings of any version are inspected. Embedded time is decoded only for the RFC variant with versions 1, 6 and 7.

Is ULID generation monotonic?

No. Each value receives fresh randomness. Values in one millisecond can appear in any order.

Sources

RFC 9562 — sections 4, 5 and Appendix A (checked 2026-11-14)
Canonical ULID specification (checked 2026-11-14)

Last reviewed 2026-11-14. The method is written out above so you can check our math.