UUID Generator

What a UUID is and why you need one

A UUID (Universally Unique Identifier), also called a GUID (Globally Unique Identifier) in Microsoft ecosystems, is a 128-bit value typically written as 32 hex digits split into five groups by hyphens, like 550e8400-e29b-41d4-a716-446655440000. It's designed to be generated independently — on different machines, at different times, with no central coordinator — while still being unique enough to use as an identifier across an entire system, or across the internet.

That's the key property that makes UUIDs so useful: unlike an auto-incrementing integer ID, which needs a single database to hand out the next number in sequence, a UUID can be generated on a client, in a mobile app, or across a hundred distributed servers simultaneously, with no risk of two of them accidentally producing the same value.

This tool generates UUIDs using your browser's built-in cryptographically secure random number generator (crypto.getRandomValues), entirely client-side — nothing is sent anywhere, and every UUID you generate is independent of every other.

UUID versions: why v4 is the one people actually want

The UUID spec (RFC 4122, updated by RFC 9562) defines several versions that differ in how the bits are derived. Version 1 encodes the current timestamp and the generating machine's MAC address, which made it useful historically but leaks information about when and where an ID was created — a privacy and security concern. Version 3 and version 5 are deterministic: they hash a namespace plus a name (MD5 for v3, SHA-1 for v5) so the same input always produces the same UUID, which is useful for generating stable IDs from existing data rather than random ones.

Version 4 is pure randomness: 122 of its 128 bits come straight from a random number generator, with the remaining 6 bits fixed to mark the version and variant per the spec [2](https://createuuid.com/uuid-v4-generator). This is what almost everyone means when they say "generate a UUID," and it's what this tool produces — no timestamp, no machine identifier, no input data required, just a fresh random identifier every time.

Version 7, a newer addition to the spec, embeds a millisecond timestamp in the leading bits so UUIDs sort roughly in creation order — useful for database indexes where you want good insert locality. It trades a little randomness (and a sliver of timestamp privacy) for sortability. If your database performance depends on sequential-ish primary keys, v7 is worth knowing about, though v4 remains the safe, general-purpose default.

How random is random enough? The collision math

A version 4 UUID has 122 random bits, giving 2^122 possible values — roughly 5.3 undecillion (5.3 × 10^36) combinations. The commonly cited birthday-paradox estimate is that you'd need to generate about 1 billion UUIDs per second for around 85 years before there's a 50% chance of a single collision anywhere in that entire set.

For virtually every real-world system — even ones generating millions of IDs a day — the probability of two v4 UUIDs colliding is close enough to zero that it isn't a practical engineering concern, provided the random number generator behind them is genuinely unpredictable. That's why this tool uses the Web Crypto API rather than Math.random(): Math.random() is not cryptographically secure and, on some engines, has a smaller internal state that makes collisions and predictability more plausible over huge volumes.

Where collisions do happen in practice, the cause is almost never bad luck — it's a broken or seeded random source, a bug that reuses the same UUID across requests (like caching a generated value where it shouldn't be cached), or code that accidentally regenerates identical UUIDs from a fixed seed.

UUID formats: hyphenated, braces, uppercase, no dashes

The canonical text form groups the 32 hex characters as 8-4-4-4-12, separated by hyphens: xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx. The '4' in the third group marks version 4, and the leading character of the fourth group (y) is always 8, 9, a, or b, marking the RFC 4122 variant — this is how you can visually confirm a string really is a v4 UUID rather than some other kind of random hex.

Microsoft's GUID convention sometimes wraps the same value in curly braces, like {550e8400-e29b-41d4-a716-446655440000}, used historically in Windows registry keys and COM object identifiers. Functionally it's the identical 128-bit value — just a different textual wrapper [3](https://guidgenerator.com/).

Some systems strip the hyphens entirely for a compact 32-character string (550e8400e29b41d4a716446655440000), which saves a few bytes and avoids hyphen-related parsing issues in URLs or filenames. Uppercase versus lowercase hex is a pure formatting choice with no meaning difference — some codebases prefer uppercase for readability, but lowercase is far more common in modern APIs and is what RFC 4122 uses in its examples.

Worked example: reading a UUID's structure

Take 3fa85f64-5717-4562-b3fc-2c963f66afa6. Split it into its five groups: 3fa85f64 (8 chars), 5717 (4 chars), 4562 (4 chars), b3fc (4 chars), 2c963f66afa6 (12 chars) — 32 hex characters total, 128 bits. The third group starts with '4', confirming this is version 4. The fourth group starts with 'b', which falls in the 8-9-a-b range required by the RFC 4122 variant bit pattern.

If you generated ten of these back to back, you'd see the third group always start with 4 and the fourth group always start with 8, 9, a, or b — everything else varies completely and unpredictably, because those are the only bits the spec reserves for metadata; the rest is free entropy.

Using UUIDs as database primary keys

UUIDs as primary keys let you generate a valid ID before a row is even inserted — useful for client-side ID generation, offline-first apps, and merging data from multiple databases without key collisions [1](https://www.thefreeaitools.com/tools/uuid-generator). This sidesteps the classic problem of auto-increment IDs, which require a round trip to the database (or a separate ID service) before you know what ID a new row will have.

The tradeoff is index performance: random UUIDv4 values scatter across a B-tree index unpredictably, which can hurt insert performance and increase index fragmentation on very large tables compared to sequential integers. This is exactly the problem UUIDv7 addresses, since its embedded timestamp keeps new values roughly sorted and clustered near the end of the index, closer to how auto-increment IDs behave.

Storage size is another consideration: a UUID takes 16 bytes in binary form (36 bytes as a hyphenated string) versus 4 or 8 bytes for a typical integer ID. Across millions of rows and their foreign key references, that difference adds up in both storage and index size — worth weighing against the operational convenience UUIDs provide.

Common mistakes people make with UUIDs

Storing UUIDs as plain text (varchar/char columns) instead of a native UUID/binary type wastes space and slows down comparisons and indexing in most databases — PostgreSQL, MySQL, and SQL Server all offer dedicated UUID or binary(16) storage that's more compact and faster to index than a 36-character string.

Assuming UUIDs are unguessable secrets is a real security mistake. A v4 UUID's randomness makes it hard to enumerate, but it was never designed as a cryptographic secret with confidentiality guarantees — using bare UUIDs as password-reset tokens or session identifiers without additional entropy or expiry checks is weaker than a purpose-built token generated for that job.

Mixing UUID versions inconsistently across a system — some tables using v1, others v4, others custom formats — makes debugging and validation harder. Pick one version per use case (v4 for opaque random IDs, v7 if you need sortable keys) and stay consistent.

Privacy and security notes

This tool generates UUIDs entirely in your browser using the Web Crypto API's secure random number generator — no UUIDs are transmitted to a server, logged, or stored anywhere outside your own session, so it's safe to generate IDs for private projects, internal tools, or anything sensitive.

Because version 4 UUIDs carry no embedded timestamp or machine information, they don't leak metadata about when or where they were created, unlike version 1. If privacy of the generation context matters to you, v4 (or v7 if you only need coarse timestamp ordering) is the safer choice over v1.

Bulk generation and common use cases

Generating many UUIDs at once is useful for seeding test databases, pre-allocating identifiers for a batch import, or creating sample data for a demo without touching production systems [5](https://lans.cloud/uuid-generator). Each one generated this way is fully independent — there's no relationship or sequence between them beyond the order you happened to generate them in.

Typical real-world uses include primary keys in distributed databases, session tokens (paired with proper expiry and secure transport), correlation IDs for tracing a request across microservices, unique filenames for uploaded files to avoid collisions, and idempotency keys for API requests so a retried request isn't processed twice.