UUID v4 Generator

A UUID (Universally Unique Identifier) is a 128-bit value formatted as 32 hex digits in five groups, like f47ac10b-58cc-4372-a567-0e02b2c3d479. Version 4 sets 122 of those bits from a random source, with the remaining 6 fixed to mark it as version 4 per the RFC — which means two UUID v4 values colliding by chance is astronomically unlikely, close enough to impossible for any practical purpose.

Everything happens in your browser — nothing is sent anywhere, and every UUID comes from the platform's cryptographic random source (crypto.randomUUID or crypto.getRandomValues), not Math.random. That matters if the identifier will ever be used as anything more sensitive than a display label — Math.random-derived IDs are predictable enough to be guessed, which a CSPRNG-backed UUID v4 is specifically designed not to be.

Generating several at once is useful for seeding test fixtures, populating a mock dataset, or grabbing a batch of message keys without round-tripping to a script each time.

UUID v4 vs. UUID v7

Because every bit is random, UUID v4 values don't sort chronologically and compress poorly in a database index — inserting them as a primary key causes random-order page splits that hurt write performance at scale. UUID v7 exists specifically to fix this: it leads with a timestamp so values sort in creation order while staying globally unique. This tool only generates v4; if insertion order matters for your use case, look for a v7 generator instead.

Not a substitute for a secret token

A UUID being unpredictable and a UUID being secret are different properties. UUID v4 is designed so that generating two by chance won't collide, not so that a third party can't enumerate or replay one — don't use a bare UUID as a password-reset token, an API key, or anything else that needs to resist a targeted guess, without additional signing or a dedicated secret-token generator.

Version and variant bits

The 4 at the start of the third group (4372 in the example above) marks the UUID version, and the leading bits of the fourth group are fixed to mark the RFC 4122 variant — both are set automatically here and aren't part of the random payload, so don't assume all 128 bits are unpredictable when reasoning about collision odds.