How to Generate UUIDs for Development and Databases
Generate UUIDs for development with a free browser-based tool. Understand the differences between UUID v1 (time-based), v4 (random), and v7 (time-ordered) and when to use each for database primary keys, distributed systems, and API identifiers. Learn why UUID v4 collision probability is negligible — the birthday problem says you need 2.7×10¹⁸ UUIDs for a 50% chance of one collision — and how v7 improves B-tree index performance.
Every record in a database needs a unique identifier. Auto-incrementing integers work — until you have multiple servers, need to merge datasets, or want to expose IDs in URLs without revealing how many records you have. UUIDs solve all three problems, and generating them takes one click with a free tool.
What is a UUID?
UUID stands for Universally Unique Identifier. It is a 128-bit number typically displayed as 36 characters: 550e8400-e29b-41d4-a716-446655440000. There are several UUID versions, but v4 is the most common — it uses random numbers, making collisions astronomically unlikely. The ToolStand UUID Generator uses the browser crypto.getRandomValues() API, ensuring cryptographically secure randomness.
When to use UUIDs
Distributed systems. Multiple servers can generate IDs independently without coordination — no central sequence counter needed. Public APIs. Exposing UUIDs in URLs does not leak information about how many records exist. An auto-incrementing ID of 1073 tells competitors you have at least 1,073 customers. A UUID reveals nothing. Database merging. When combining data from multiple sources, UUIDs never conflict. Merging two tables with integer primary keys is a headache; merging UUIDs is trivial.
UUID v1 vs v4 vs v7 — understanding the tradeoffs
Not all UUIDs are created equal. UUID v1 encodes the MAC address and timestamp — it is predictable and sortable, but leaks hardware identity. UUID v4 uses 122 random bits (plus 6 version/variant bits), making it the most common choice for general-purpose IDs. UUID v7 (RFC 9562) puts a Unix timestamp in the first 48 bits followed by random data, creating time-sortable IDs that do not fragment database indexes. If you are using UUIDs as primary keys in PostgreSQL or MySQL, v7 can significantly reduce write amplification compared to v4. The UUID Generator supports v1, v4, and v7 — switch between them to see how the string structure changes.
The birthday problem — how likely is a UUID collision?
UUID v4 has 122 random bits, giving 2¹²² ≈ 5.3×10³⁶ possible values. The birthday problem tells us that you need roughly the square root of that — about 2.7×10¹⁸ UUIDs — for a 50% chance of a single collision. To put that in perspective: generating one billion UUIDs per second would take 85 years to reach that threshold. In practice, you are far more likely to be struck by a meteorite while winning the lottery than to see a UUID v4 collision in production. The real risk is not collision but predictability: UUID v1 exposes the generating machine's MAC address and timestamp. For security-sensitive contexts, always prefer v4 or v7.
UUIDs as database primary keys — the index fragmentation problem
Using random UUID v4 as a clustered primary key in a B-tree index causes page splits because new rows insert at random positions rather than at the end. This fragments the index and degrades write performance. PostgreSQL mitigates this with non-clustered indexes, but MySQL InnoDB always clusters on the primary key. UUID v7 solves this: the timestamp prefix ensures new UUIDs are roughly sequential, so inserts go to the end of the index. If you cannot use v7 yet, consider a ULID or Snowflake-style ID for write-heavy tables. For read-heavy workloads where UUID lookup is infrequent, the fragmentation cost is acceptable.
How the UUID Generator tool works under the hood
The UUID Generator uses the browser's crypto.getRandomValues() API — a cryptographically secure random number generator — to produce UUID v4. This is the same API used by Web Crypto for key generation. For UUID v1, it derives the node ID from crypto.getRandomValues() instead of the real MAC address (a privacy improvement over RFC 4122). For UUID v7, it combines Date.now() with random bytes per RFC 9562. All generation happens client-side — no UUIDs are transmitted to any server. You can generate up to 100 UUIDs at once with a single click, and the copy button lets you grab them all as a comma-separated list.
UUIDs in different languages
Most programming languages have native UUID support: Python has the uuid module, JavaScript can use crypto.randomUUID(), Java has java.util.UUID, and Go has google/uuid. But for quick generation — especially when you are writing config files, creating test data, or need a one-off ID — the browser-based generator is faster than opening a REPL or writing a script.
Explore the full collection of free tools at toolstand.io. Free, forever. No sign-up. No download. Just tools that work.
Frequently Asked Questions
Are UUIDs suitable for URLs and REST API resource identifiers?
Yes, UUIDs are excellent for REST API resource IDs because they do not leak information about record count or creation order (unlike auto-increment integers). However, UUIDs are 36 characters long, making URLs less human-readable. If you need shorter IDs, consider base62-encoded UUIDs (22 characters) or ULIDs (26 characters). For public-facing URLs where readability matters, a short slug with a UUID backend is the best compromise.
What happens if I use a UUID as a primary key in MySQL?
InnoDB stores rows in primary key order, and random UUID v4 values cause inserts at random locations in the clustered index. This leads to page splits, index fragmentation, and slower writes. UUID v7 mitigates this because the timestamp prefix ensures new UUIDs are mostly sequential. If you must use UUID v4 with MySQL, set innodb_fill_factor lower and schedule regular OPTIMIZE TABLE operations. For new projects, consider UUID v7 or a dedicated UUID-to-binary function that rearranges bits for better indexing.
What is the difference between UUID and GUID?
UUID (Universally Unique Identifier) and GUID (Globally Unique Identifier) are functionally identical. GUID is Microsoft's implementation of the UUID standard, and the terms are used interchangeably in practice. Both follow the same 128-bit, 36-character format (8-4-4-4-12 hex digits). The only distinction is historical: Microsoft documentation says GUID, IETF RFC 9562 says UUID. When you generate a UUID on macOS or Linux and a GUID on Windows, you get the same result.
Can UUIDs be sequential and unique at the same time?
UUID v7 is designed exactly for this: the first 48 bits are a Unix timestamp in milliseconds, making them sortable and roughly sequential, while the remaining bits are random for uniqueness. This gives you the best of both worlds — database-friendly ordering and negligible collision probability. UUID v6 (rare, proposed in RFC 9562 alongside v7) is another time-ordered variant using a different timestamp layout.
How many UUIDs can I generate before worrying about a duplicate?
For UUID v4, you need approximately 2.7×10¹⁸ generations to reach a 50% collision probability. At one billion UUIDs per second, that takes about 85 years. For any practical application — even Google-scale systems generating millions of UUIDs per second — a v4 collision is astronomically unlikely. UUID v7 has the same random-bit count, so collision probability is identical. The risk is not collision; the risk is using a weak random number generator.
Why does my UUID say version 4 when I asked for version 1?
Check the 13th character of the UUID. For v1, it should be '1'; for v4, '4'; for v7, '7'. If the version digit is wrong, the generator is likely using a fallback method. All major browsers support crypto.getRandomValues() (the v4/v7 source), but if you are in an older environment, the tool falls back to a non-cryptographic PRNG — and v1 generation may be unavailable. The generator's interface shows which version each output UUID is.