UUID Generator
Set your options and generate — every UUID is created fresh in your browser, nothing is uploaded.
RFC 4122 version 4, with a real fallback
This generator uses crypto.randomUUID(), a built-in
browser method that returns a spec-compliant v4 UUID directly —
it's supported universally across current versions of every major
browser. As a safety net, the tool also ships a documented
crypto.getRandomValues()-based fallback that builds
the same v4 format by hand (setting the version and variant bits
manually), used automatically if randomUUID isn't
available in a given environment. Either path uses a
cryptographically secure random source, not Math.random().
Your uppercase and no-hyphens choices are applied to the result
afterward as simple text transforms.
Worked example
Generating one UUID might produce
502fb771-2b2b-4f9f-bb91-ffc7ee8269f2. Note the
4 at the start of the third group — that's the fixed
version digit — and the b at the start of the fourth
group, which is always one of 8, 9, a, b, the fixed
variant bits. Ticking "Uppercase" turns it into
502FB771-2B2B-4F9F-BB91-FFC7EE8269F2; unticking
"Hyphens" turns it into
502fb7712b2b4f9fbb91ffc7ee8269f2.
Frequently asked questions
What is a UUID?
A Universally Unique Identifier is a 128-bit value, usually written as 32 hex digits in five hyphenated groups (8-4-4-4-12), used to label something — a database row, a session, a file — without a central authority handing out numbers. Any two systems can generate UUIDs independently and, in practice, never collide.
What does 'v4' mean?
It's one of several UUID versions defined by RFC 4122, and it describes how the bits are produced. Version 4 is random-based: aside from a handful of fixed version and variant bits, every bit comes from a random number generator. That's different from version 1, which encodes the current timestamp and a node identifier — v1 IDs reveal roughly when (and sometimes where) they were created; v4 IDs reveal nothing but themselves.
Are these guaranteed unique?
Not mathematically guaranteed — but close enough that it doesn't matter in practice. A v4 UUID has 122 random bits, so the chance of ever generating two identical ones is astronomically small: you'd need to generate roughly a billion UUIDs per second for about 85 years before the odds of a single collision reached 50%. Treat it as unique; don't build a system whose only safety net is a formal mathematical proof of zero collisions.
Can I use these as database primary keys?
Yes, it's common practice, with a real tradeoff to know about. Because v4 values are random, inserting them into an index (especially a clustered/B-tree primary key) scatters writes across the whole index rather than appending at the end, which can fragment the index and hurt insert performance at scale — unlike sequential integer or time-ordered IDs. Many teams accept that cost for the benefits of unpredictable, mergeable, centrally-uncoordinated IDs; others switch to time-ordered variants (like UUIDv7) specifically to avoid it. There's no universally correct choice — it depends on your write volume and access patterns.