UUID Generator is a free online tool that produces RFC 4122 version 4 UUIDs using crypto.randomUUID() where the browser supports it, falling back to a manual crypto.getRandomValues()-based implementation otherwise. Generate anywhere from 1 to 100 at once, toggle uppercase output, toggle hyphens on or off, and copy the entire batch or any single value in one click.
A UUID (Universally Unique Identifier, also called a GUID — Globally Unique Identifier — in Microsoft ecosystems, the two terms refer to the same 128-bit format) exists to solve a specific coordination problem: generating an identifier that is guaranteed unique without any central authority handing out the next available number. An auto-incrementing integer primary key works fine on a single database, but the moment you have multiple independent services, offline clients, or sharded databases all creating new records simultaneously, nobody can hand out sequential numbers without a coordination bottleneck. UUIDs sidestep this entirely — any machine, anywhere, with no network connection and no shared state, can generate an identifier so unlikely to collide with any other UUID ever generated that the probability is treated as zero for all practical purposes.
There are several UUID versions defined by RFC 4122, and they are not interchangeable in what they reveal or guarantee. Version 1 is time-based and incorporates the generating machine's MAC address, which made it useful historically for sortable identifiers but is now largely avoided because embedding a MAC address leaks identifying hardware information. Versions 3 and 5 are deterministic — they hash a namespace and a name together (MD5 for v3, SHA-1 for v5), so the same input always produces the same UUID, which is useful for generating a stable ID from an existing value like a URL or email address rather than for creating a new random one. Version 4, the version this tool generates exclusively, is the simplest and by far the most common in modern application development: it is 122 bits of pure randomness with no embedded machine information, no timestamp, and no dependency on external input, which is exactly what you want for a general-purpose unique identifier. Newer time-ordered variants (v6 and v7) exist in more recent specifications to combine v4-style randomness with a sortable timestamp prefix, addressing the database index fragmentation that purely random v4 values can cause on very large tables — this tool sticks to standard v4 since it remains the most broadly supported and requested format across programming languages and databases.
The math behind why v4 collisions are considered practically impossible is worth being concrete about: of the 128 total bits, 6 are fixed (4 bits set the version to 0100, 2 bits set the variant to 10), leaving 122 bits of actual randomness. That is roughly 5.3 × 10^36 possible values. Using the birthday-paradox approximation, you would need to generate about 2.71 quintillion UUIDs before the probability of a single collision reached just 50% — a rate of a billion UUIDs generated every second would still take over 85 years to reach that point. This is why UUID v4 is trusted as a primary key in distributed databases, a correlation ID in distributed tracing, and a resource identifier in public APIs without any deduplication check against existing values.
Generation here uses crypto.randomUUID(), a native browser method built directly on the same operating-system cryptographic random number generator used for TLS keys, available in all current browser versions. Where that method is unavailable, the fallback path draws 16 random bytes from crypto.getRandomValues() and manually sets the version and variant bits per the RFC 4122 specification, producing an identical result. Either path avoids Math.random(), which is not cryptographically secure and should never be used to generate identifiers that need genuine unpredictability. Everything runs locally with zero network calls.
Need a secret string instead of an identifier? Password Generator uses the same cryptographically secure randomness for that case.