tooloora

UUID Generator — v4 and v7, single or bulk

Generate random UUID v4 or time-sortable UUID v7, 1 to 100 at once, copy single values or the whole list. Created locally with Web Crypto, nothing is sent.

Runs locally — nothing is uploaded

    Generated locally with your browser's Web Crypto API – nothing is sent.

    Generate UUIDs: v4 and v7

    Generate 1 to 100 UUIDs at once, either random v4 or time-sortable v7, with an uppercase option, per-row copy and copy-all. The random bits come from your browser's Web Crypto API, a cryptographically secure source. Nothing is sent to any server, and the tool works offline.

    What is a UUID?

    A Universally Unique Identifier is a 128-bit value written as 36 characters in five hex groups (8-4-4-4-12). The current standard is RFC 9562 (May 2024), which obsoletes the older RFC 4122 and defines the new time-based versions 6, 7 and 8 alongside the classics. UUIDs can be generated decentrally, with no central authority, and collisions are practically impossible: a v4 UUID carries 122 random bits, about 5.3 × 10^36 possible values.

    v4 or v7, which should you pick?

    • v4 (random): maximum anonymity, reveals nothing about when or in what order it was created. Good for publicly visible IDs, tokens, file names.
    • v7 (time-based): starts with a 48-bit Unix millisecond timestamp followed by 74 random bits (RFC 9562 §5.7). v7 values sort roughly by creation time, which makes them clearly better database primary keys: new rows land next to each other in the index instead of scattering, reducing page splits and cache misses compared to v4 keys.

    In short: database keys → v7, everything else → v4.

    How honest is the v7 sortability here?

    Our v7 implementation follows RFC 9562 but deliberately omits the optional monotonic counter: UUIDs created in the same millisecond share the time prefix while the rest is random, so their relative order is undefined. Across millisecond boundaries the ordering is always correct. For the vast majority of uses (database keys, log correlation) that is enough; if you need strict monotonicity, add a counter in the database.

    A second honest note: a v7 UUID contains its creation time in the clear, anyone can read the first 48 bits as a timestamp. If that is undesirable, use v4.

    Where does the randomness come from?

    From crypto.randomUUID and crypto.getRandomValues, the browser's cryptographically secure random generator, not from Math.random. Everything happens locally on your device: no server generates, sees or logs your IDs.

    Frequently asked questions

    What is the difference between UUID v4 and v7?

    v4 is fully random: 122 of its 128 bits come from a cryptographic random source. v7, standardized in RFC 9562 (May 2024), starts with a 48-bit Unix millisecond timestamp followed by 74 random bits, so v7 values sort roughly by creation time. That makes v7 a better database primary key because inserts stay close together in the index, while v4 reveals nothing about when it was created.

    Are the UUIDs generated on a server?

    No. Every UUID is generated in your browser with the Web Crypto API (crypto.randomUUID and crypto.getRandomValues), a cryptographically secure random source. Nothing is requested from or sent to any server, so no one else ever sees your identifiers, and the tool works offline.

    Can two generated UUIDs collide?

    In practice no. A v4 UUID has 122 random bits, giving about 5.3 undecillion (5.3 × 10^36) possible values. You would need to generate roughly 100 trillion UUIDs before the collision probability reaches even one in a billion. Collisions are a theoretical concern, not a practical one, as long as a proper random source is used, which is the case here.

    Is the v7 order guaranteed within the same millisecond?

    No, and this tool is honest about it: our v7 implementation has no monotonic counter, so UUIDs created in the same millisecond share the timestamp prefix but their remaining bits are random, meaning their relative order is undefined. Across different milliseconds the ordering is correct. RFC 9562 describes optional counter methods for strict monotonicity; databases that need it usually add their own.

    Does a v7 UUID leak information?

    It contains its creation time: the first 48 bits are the Unix timestamp in milliseconds, which anyone can read out. That is by design and usually harmless, but if the creation moment itself is sensitive, use v4, which encodes nothing but randomness.

    Related tools

    Password Generator — strong, random & localStrong random passwords with length, character classes and a strength meter.Hash Generator — SHA-256, SHA-512 & more, localSHA-1/256/384/512 checksums of text via Web Crypto, all live, 100% in your browser.Unix Timestamp Converter — epoch to date and backTimestamp to date and back, seconds/ms auto-detected, all IANA time zones, live clock.