Generate cryptographically secure UUIDs — classic random v4 or modern time-sortable v7 — one at a time or in bulk, with formatting options for every database and language convention.
Click any line to copy just that UUID.
A UUID (Universally Unique Identifier, called GUID in the Microsoft world) is a 128-bit number written as 36 characters: 3f2504e0-4f89-41d3-9a0c-0305e82c3301. Its promise is uniqueness without coordination — two servers, two apps, two teams can generate IDs simultaneously with no central authority and no realistic chance of collision. A v4 UUID contains 122 random bits, giving 5.3×1036 possible values; you'd need to generate a billion UUIDs per second for about 85 years before the odds of a single collision reached 50%. That math is why UUIDs are the default identifier in distributed systems, APIs, message queues, and databases where auto-increment counters can't work.
This generator uses your browser's crypto API — the cryptographically secure random source — never Math.random(), whose output is predictable and has caused real-world ID-collision bugs in careless implementations.
v4 (fully random) is the universal standard — maximum entropy, zero information leakage, supported by every library. Its weakness appears at database scale: random values scatter inserts across a B-tree index, causing page splits and cache misses that measurably slow large tables. v7 (time-ordered), standardized in RFC 9562 (2024), fixes exactly this: its first 48 bits are a Unix millisecond timestamp, so IDs generated later sort later — inserts land at the index's end like auto-increment, keeping writes fast, while 74 random bits still guarantee uniqueness. The rule of thumb: v7 for database primary keys, v4 when IDs are exposed and creation time must not leak (a v7 ID reveals when the record was created — usually harmless, occasionally sensitive, e.g. user signup dates). You can decode a v7's embedded timestamp with our Timestamp Converter — the first 12 hex characters are the millisecond value.
The canonical form is lowercase with hyphens (RFC 9562 requires generators to emit lowercase). Microsoft ecosystems — SQL Server, .NET, registry keys — traditionally display GUIDs in uppercase and sometimes wrapped in braces: {3F2504E0-...}. Some databases and URLs use the 32-character no-hyphen form to save space. The checkboxes above cover all three conventions; the underlying value is identical, so use whatever your target system displays — comparisons should always be case-insensitive.
Theoretically yes, practically no — the probability is so far below hardware failure rates that every major system treats UUIDs as unique by assumption. Collisions in the wild have only ever come from broken generators using weak randomness, not from the format itself.
A v4 from a crypto-secure source has 122 unguessable bits — technically strong. But convention matters: UUIDs get logged, indexed, and shared as identifiers precisely because nobody treats them as secrets. For API keys and session tokens, generate dedicated secrets (see our Password Generator); use UUIDs to name things, not to protect them.
The 13th hex digit states the version (4 or 7 here), and the 17th encodes the variant (8, 9, a, or b for standard UUIDs). They're why you can identify a UUID's type at a glance — and why you can't just invent 32 random hex digits and call it a valid UUID.
No — generation is pure client-side JavaScript. Load the page, go offline, and it still works; no generated ID is ever transmitted or logged.
Integers are smaller and faster on a single database; UUIDs win the moment IDs are generated on multiple machines, exposed in URLs (no guessable sequence), or merged across environments. v7 UUIDs close most of the performance gap, which is why they're rapidly becoming the modern default.
v1 embeds your MAC address and timestamp — a privacy leak that famously helped identify the Melissa virus author, and the reason random v4 took over. v3/v5 are deterministic: they hash a name within a namespace, so the same input always yields the same UUID — useful for stable IDs, irrelevant for general generation. v4 and v7 cover modern needs.
00000000-0000-0000-0000-000000000000 is a reserved "no value" UUID, valid by format but never generated randomly. Seeing it in your data almost always means an uninitialized field rather than an astronomical coincidence — treat it as a bug signal.