UUID Generator - Generate & Validate UUIDs Online

How to Use the UUID Generator

Click the Generate UUID button to create a new version 4 UUID instantly. The result appears in a large monospace display with a one-click copy button beside it. To generate multiple UUIDs at once, increase the quantity using the stepper control — you can create up to 100 UUIDs in a single batch. The bulk output appears in a scrollable text area with a Copy All button that places every UUID on your clipboard, separated by newlines, ready to paste into a database seed file, test fixture, or configuration document.

Use the format chips to control how your UUIDs are displayed. Standard uses the canonical 8-4-4-4-12 hyphenated form. No Dashes strips the hyphens for systems that expect a plain 32-character hex string. Uppercase converts the output to capital letters, which some enterprise APIs require. Braces wraps the UUID in curly braces, matching the format used by Microsoft COM/OLE and certain Windows registry entries. The format selection persists across generations, so you can keep clicking Generate without re-selecting your preferred style.

UUID Versions Explained

The UUID specification (RFC 9562, which supersedes RFC 4122) defines several versions, each with different generation strategies and trade-offs. Version 1 encodes a timestamp and the generating host’s MAC address, producing monotonically increasing values that are excellent for database indexing but leak information about when and where they were created. Version 3 and Version 5 are deterministic — given the same namespace UUID and name string, they always produce the same output. Version 3 uses MD5 internally while Version 5 uses SHA-1, making v5 the preferred choice for new applications. Version 4 is generated from cryptographically secure random numbers. It is the most widely used version in modern software because it requires no coordination, no clock, and no network address. Version 7 is a newer addition that combines a Unix timestamp prefix with random data, giving you time-sortable identifiers without exposing a MAC address. It is gaining traction in database-heavy applications where index locality matters.

When to Use Which UUID Version

For most applications, v4 is the correct default. It works everywhere, has no external dependencies, and its collision probability is negligible at any realistic scale. Choose v1 when you need monotonically increasing identifiers for time-series data or database primary keys where B-tree index fragmentation is a concern — but be aware that v1 UUIDs expose both the creation timestamp and the generating machine’s MAC address, which may be unacceptable in privacy-sensitive contexts. Use v5 when you need deterministic, reproducible identifiers derived from a name within a namespace — for example, generating a stable UUID for a DNS hostname or a URL so that the same input always maps to the same UUID across different systems without any shared state. If your primary concern is database write performance and you are designing a new system from scratch, evaluate v7 — its timestamp prefix ensures that new rows are appended near the end of the B-tree rather than scattered randomly, which can dramatically reduce page splits and write amplification on large tables.

Collision Probability and the Birthday Paradox

A version 4 UUID contains 122 random bits (6 bits are fixed for version and variant markers). The total keyspace is 2¹²², which is approximately 5.3 × 10³⁶ possible values. The probability of a collision follows the birthday paradox: after generating n UUIDs, the probability of at least one duplicate is roughly n² / (2 × 2¹²²). To reach a 50% collision probability, you would need about 2.7 × 10¹⁸ UUIDs — that is 2.7 quintillion. At a rate of one billion UUIDs per second, it would take approximately 85 years to reach that threshold. In practice, your storage system will fail long before your UUIDs collide. That said, collision resistance depends entirely on the quality of the random number generator. Always use crypto.getRandomValues() in browsers or /dev/urandom on servers — never use Math.random() for UUID generation, as it is not cryptographically secure and can produce predictable sequences.

UUIDs vs Auto-Increment IDs in Databases

Auto-incrementing integer IDs are simple, compact, and fast for B-tree indexing. However, they have significant drawbacks in distributed architectures. Sequential IDs leak information about your data volume and growth rate (a user can guess how many records exists by observing their own ID). They require a centralized authority to assign the next value, making horizontal scaling and multi-region writes difficult without coordination. They also create merge conflicts when combining data from independent database shards. UUIDs solve all three problems at the cost of larger storage (16 bytes vs 4–8 bytes for integers) and reduced index locality for random v4 UUIDs. The storage overhead is negligible on modern systems, and the index locality issue is addressable by switching to v1 or v7. For most web applications and microservice architectures, UUIDs are the better default. Reserve auto-increment IDs for high-volume append-only tables where storage efficiency and insert throughput are critical, and where the data never needs to be merged across independent databases.

Storing and Indexing UUIDs in Databases

When using UUIDs as primary keys, the storage format matters more than most developers expect. Storing a UUID as VARCHAR(36) preserves the human-readable hyphenated form but consumes 36 bytes per value and makes index comparisons slower than necessary. A BINARY(16) column stores the raw 16-byte value, cutting index size by more than half and improving lookup throughput noticeably at scale. MySQL’s built-in UUID_TO_BIN() and BIN_TO_UUID() functions handle the conversion, and the optional swap flag reorders the time-based bytes of v1 UUIDs to improve index locality. For new schemas, UUID v7 sidesteps this concern entirely because its timestamp prefix guarantees that new rows are inserted in roughly ascending order, dramatically reducing B-tree page splits and write amplification compared to fully random v4 UUIDs.

UUID Security Considerations

A version 4 UUID is generated from 122 bits of cryptographically secure random data, making it statistically unguessable. However, a UUID is not a security token. Its purpose is uniqueness, not secrecy, and it provides no authentication or authorization guarantees on its own. Version 1 UUIDs pose a more concrete privacy risk because they embed the generating host’s MAC address and a timestamp, allowing observers to reconstruct when and on which machine an identifier was created. Always generate v4 UUIDs using a CSPRNG — the browser’s crypto.getRandomValues() or the server’s /dev/urandom — and never use Math.random(), whose output is predictable and unsuitable for identifier generation. If you need a secret token for session management or API access, use a dedicated token library rather than a UUID.

For tasks that often go hand-in-hand with UUID generation, explore these related tools: the Hash Generator lets you produce SHA-256 or MD5 digests from strings, which is useful when building v5 namespace UUIDs from deterministic inputs, and the JSON Formatter & Validator helps you inspect and clean up the JSON payloads where UUIDs commonly appear as identifiers in API responses and database seed files.