Generate random v4 or time-ordered v7 UUIDs in bulk, with formatting options — produced locally by your browser's cryptographic RNG.
v4 is 122 bits of randomness — the safe default when an identifier should reveal nothing about when or where it was made. v7 prefixes a 48-bit millisecond timestamp, so a sorted list of v7 ids is also in creation order.
Random primary keys scatter inserts across a B-tree index, fragmenting pages and hurting write throughput on large tables. Time-ordered keys append at the end, which is why v7 (and previously ULIDs and Snowflake ids) exist. The trade-off is that a v7 id leaks its creation time — fine for internal rows, less so for public tokens.
The canonical form is lowercase with hyphens. Uppercase and brace-wrapped variants exist mostly for Microsoft tooling; both options are here when a platform insists on them.
Related: hash generator, JSON formatter.
Yes. They come from the browser’s cryptographic random number generator (crypto.getRandomValues), the same source used for keys and tokens — not Math.random.
v7 puts a millisecond timestamp in the leading bits, so identifiers sort chronologically. That makes them far friendlier as database primary keys: inserts land at the end of the index instead of scattering across it like v4.
Practically, no. A v4 UUID has 122 random bits; you would need to generate billions per second for a century before a collision became likely.
No. Generation happens in your browser, and nothing is logged or transmitted — which is why these are safe to use as real identifiers.
It works, but v4 values arrive in random order and can scatter inserts across the index. Choose v7 when chronological sorting and index locality matter; use v4 when an embedded timestamp is undesirable.