UUID-generator

A free online UUID generator and decoder, all in your browser

This free online UUID generator creates universally unique identifiers — also known as GUIDs — instantly, with no sign-up and no limits. Every UUID is produced locally using your browser's cryptographically secure random number generator (CSPRNG), so nothing is ever sent to a server and you can safely use the IDs for production keys, test data, or sensitive systems. It works offline, generates a single ID or thousands in bulk, and pairs the generator with a built-in UUID decoder so you can both create and inspect identifiers in one place.

Whether you need one random UUID, a batch to seed a database, or a quick way to decode a UUID you've been handed, this tool covers the whole workflow — no installation, no library, and not a single line of code. It goes well beyond what sites like uuidgenerator.net or guidgenerator.com offer, combining all six UUID versions, every output format, bulk export, and a full decoder into a single private page.

Every UUID version: v1, v3, v4, v5, v6, and v7

Pick the version that fits your use case. UUID v4 is fully random and the most common choice — the same value you'd get from uuid.uuid4() in Python, java.util.UUID.randomUUID() in Java, or crypto.randomUUID() in JavaScript. UUID v7 embeds a Unix millisecond timestamp, so the IDs are time-sortable and make excellent database primary keys with far better index locality than v4. v1 and v6 are Gregorian-timestamp UUIDs (v6 is the reordered, sortable form), generated here with a random node so no MAC address is ever leaked. You can also emit the special NIL (all-zero) and Max (all-ones) values from RFC 9562.

For stable, reproducible IDs choose the name-based versions: v5 (SHA-1) and v3 (MD5) hash a namespace together with a name string, so the same inputs always yield the same UUID. Select a standard namespace — DNS, URL, OID, or X.500 — or paste your own, enter any name, and derive a deterministic identifier from a domain, URL, or key. Output matches Python's uuid.uuid5() / uuid.uuid3() exactly.

Bulk generation and flexible output formats

Generate up to 10,000 UUIDs at once and export them as plain text, a JSON array, a CSV column, or ready-to-run SQL VALUES — ideal for seeding tables, building fixtures, or creating realistic test data in seconds. Format the output to match your stack: toggle uppercase, strip hyphens for a compact form, wrap in curly braces for .NET GUID literals, or prefix with urn:uuid: for RDF and XML documents.

Because everything runs client-side, bulk generation of thousands of IDs is instant and never touches a network — making this a faster and more private alternative to uuidtools.com or the UUID panel inside it-tools.tech.

Decode and inspect any UUID online

Paste any identifier into the built-in decoder to instantly break down its structure. The online UUID decoder reports the version and variant, and for time-based UUIDs it extracts the embedded data: the exact creation timestamp from v1, v6, and v7, plus the clock sequence and node (flagging whether the node is a random value or a real MAC address) from v1 and v6. It recognises the RFC 4122/9562 variant and the NIL and Max special values, and tolerates braces, URN prefixes, mixed case, and missing hyphens.

That makes it a handy companion for everyday debugging: confirm whether an ID is truly random (v4) or time-based, recover when a v1/v6/v7 record was created, check that a name-based v3/v5 ID carries no hidden data, or simply validate that a string is a well-formed UUID before it ever reaches your code.

Which UUID version should you use?

For most needs a random v4 UUID is the right default: it carries no information about when or where it was made, which is exactly what you want for public identifiers, session tokens, or anything that shouldn't leak a creation time. Reach for v7 when the identifier is also a database key — its embedded timestamp keeps rows roughly insertion-ordered, which reduces index fragmentation and speeds up range queries on high-write tables.

Name-based v5 is ideal when you need the same UUID for the same logical entity every time — for example, deriving a stable product ID from a canonical URL. Generating UUIDs online is the fastest way to get a correct, collision-resistant ID when you don't want to drop into a REPL or wire up a library. With 122 bits of entropy behind every v4, the odds of a collision are effectively zero even at massive scale.

UtiloKit vs uuidgenerator.net, guidgenerator.com, and it-tools.tech

Uuidgenerator.net is one of the most-visited UUID tools but generates a single v4 UUID per page visit — there's no bulk mode, no v7, no decoder, and no format options. Guidgenerator.com is similar: simple, fast, but limited to one format and one version. It-tools.tech covers UUIDs as part of a larger toolbox and has a cleaner UI, but splits generation and decoding into separate screens and doesn't support bulk SQL export.

UtiloKit puts all six UUID versions (v1, v3, v4, v5, v6, v7), every format (standard, uppercase, no-hyphens, braced, URN), bulk export to JSON/CSV/SQL, and a full decoder on a single screen. Everything runs in your browser with CSPRNG — no server, no account, no file upload. The tool also works offline after the first load, which matters if you're seeding a database on a plane or in a location with unreliable connectivity.

UUID versions explained in depth: v1 through v7

UUID v1 is time-based: it encodes a 60-bit Gregorian timestamp (in 100-nanosecond intervals since October 1582) together with a clock sequence and the MAC address of the network interface that generated it. The MAC address is the key privacy problem — a v1 UUID leaks both when and where it was created, making it unsuitable for public identifiers. UUID v2 (DCE Security) is rarely encountered outside legacy Unix systems; it replaces part of the timestamp with a POSIX UID or GID, sacrificing uniqueness guarantees in the process.

UUID v3 and v5 are name-based: they hash a namespace UUID together with an arbitrary name string and encode the result as a UUID. v3 uses MD5; v5 uses SHA-1 and is the preferred choice for new code. Both are deterministic — the same namespace plus the same name always produces the same UUID, making them ideal for deriving stable IDs from URLs, domain names, or any canonical key. UUID v4 is the opposite: 122 bits of pure randomness with no embedded information, generated by the CSPRNG. It is by far the most widely used version today and what crypto.randomUUID() in JavaScript and uuid.uuid4() in Python return.

UUID v6 rearranges the timestamp fields of v1 so that the bytes sort in chronological order — fixing v1's sortability without changing its information content. UUID v7, introduced in RFC 9562 (2022), takes a cleaner approach: the first 48 bits are a standard Unix millisecond timestamp, followed by 74 bits of randomness. Because the timestamp occupies the most-significant bits, v7 UUIDs sort lexicographically in the order they were generated — making them far better database primary keys than v4 without leaking a MAC address the way v1 does. For most new projects that need sortable, globally unique IDs, v7 is now the recommended default.

UUID collision probability: why duplicates are effectively impossible

A UUID v4 contains 122 bits of random data (6 bits are reserved for version and variant). The total number of possible values is 2¹²² — roughly 5.3 × 10³⁶. The birthday problem tells us that to reach a 50% probability of generating at least one duplicate pair you would need to generate approximately 2.7 × 10¹⁸ UUIDs — 2.7 quintillion. At a throughput of one billion UUIDs per second, reaching that threshold would take 85 years of continuous generation. In any realistic system, the collision probability over the lifetime of the software is indistinguishable from zero.

The birthday paradox formula makes this precise: the number of samples needed for a collision probability p in a space of size d is approximately n ≈ √(2d × ln(1/(1−p))). With d = 2¹²² and p = 0.5, that gives 2.7 × 10¹⁸. Even for a 1-in-a-trillion chance (p = 10⁻¹²), you'd still need to generate about 2.6 billion UUIDs.

The one real-world risk is not in the mathematics but in the random number generator quality. A broken or poorly seeded PRNG dramatically reduces effective entropy — early virtual machine images that were cloned before the OS entropy pool was initialized have produced duplicate UUIDs in production. Always use a CSPRNG (like the browser's crypto.getRandomValues()) rather than Math.random() or any seeded pseudo-random source, and never fork a process without re-seeding. This tool uses the browser CSPRNG exclusively, so every UUID it produces carries the full 122 bits of entropy.

UUID as a database primary key: v4 vs v7 vs auto-increment vs ULID

Auto-increment integer IDs are compact (4 bytes for INT, 8 bytes for BIGINT), naturally ordered, and fast to index — but they reveal the row count to anyone who sees a URL or API response, and they break under distributed writes: two database servers both incrementing their own counter will generate duplicate IDs without an external coordination layer. UUID v4 (16 bytes) solves that coordination problem — every node generates globally unique IDs independently — but its random bit pattern means that consecutive inserts land at random positions in a B-tree index. As the table grows, almost every insert is a page miss, leading to index fragmentation, frequent page splits, and dramatically slower write throughput on large tables.

UUID v7 resolves this tension. Its Unix millisecond timestamp in the most-significant bits means that IDs generated close together are numerically adjacent, so inserts cluster at the right edge of the index just like auto-increment — while still being globally unique and requiring no coordination. The trade-off versus auto-increment is size (16 vs 8 bytes) and the fact that the approximate creation time is visible in the ID. For most modern applications that trade-off is well worth making. ULID (Universally Unique Lexicographically Sortable Identifier) achieves a similar result using Crockford Base32 encoding (26 characters, no hyphens, case-insensitive), which can be more readable in logs and URLs. Snowflake IDs, used at scale by Twitter and Discord, pack a 41-bit millisecond timestamp, a datacenter ID, a worker ID, and a sequence number into a 64-bit integer — time-sortable, extremely fast, but requiring central assignment of worker IDs.

The practical decision tree: use UUID v7 for most new projects needing globally unique, sortable primary keys; use UUID v4 when you explicitly want IDs that reveal nothing about creation time or ordering; use ULID if you need time-sortable IDs with cleaner URL representations and cross-language ecosystem support; and consider Snowflake only when you are operating at Twitter-scale and can manage the worker ID assignment infrastructure.

Alternative unique identifiers: ULID, NanoID, CUID, and MongoDB ObjectID

The UUID specification is not the only way to generate globally unique identifiers, and for some use cases alternatives have real advantages. ULID (Universally Unique Lexicographically Sortable Identifier) encodes 48 bits of millisecond timestamp and 80 bits of randomness into 26 characters of Crockford Base32 — making it URL-safe, case-insensitive, and time-sortable without any hyphens. NanoID takes a different angle: it uses a URL-safe alphabet (A–Za–z0–9_-) to produce 21-character IDs with collision resistance comparable to UUID v4, while being roughly 40% smaller as a string. NanoID is particularly popular in JavaScript environments where short, clean IDs are preferred over the 36-character UUID hex format.

CUID (Collision-resistant Unique ID) was designed specifically for web use: it concatenates a timestamp, a browser fingerprint, a per-process counter, and random bytes, producing IDs that are resistant to collision even across multiple clients simultaneously. MongoDB ObjectID is a 12-byte identifier (rendered as 24 hex characters) that packs a 4-byte Unix timestamp, a 5-byte machine-and-process identifier, and a 3-byte random counter — similar in spirit to UUID v7 in that it is time-sortable and embeds machine identity, predating the UUID v7 specification by over a decade.

Choosing between these formats comes down to your constraints. If you need broad RFC compliance and ecosystem support (every major database, ORM, and language has UUID support built in), use UUID v7 for sortable keys and UUID v4 for opaque tokens. If you need short strings in URLs, NanoID or ULID are excellent choices. If you are already in the MongoDB ecosystem, ObjectID is the natural fit. The key insight is that all of these formats solve the same core problem — generating an identifier that is globally unique without central coordination — and the differences are in the trade-offs between size, sortability, readability, and information exposure.