Random UUID Generator

How to generate random UUIDs?

UUIDs (Universally Unique Identifiers) are 128-bit identifiers used across software systems. Here's exactly how to generate and use them:

• Select your UUID version from the dropdown: Version 4 (random) for most general-purpose needs, Version 1 (time-based) when you need traceability through embedded timestamps, or Version 7 (time-sortable) for modern databases that benefit from lexicographic ordering.
• Choose whether to include or exclude hyphens in the output. Standard UUID format uses hyphens (550e8400-e29b-41d4-a716-446655440000), while some systems prefer compact hex strings without separators (550e8400e29b41d4a716446655440000).
• Set how many UUIDs to generate at once — select from 1 to 100. Generating multiple UUIDs is useful for creating primary keys, session tokens, or batch identifiers for database seeding.
• Click 'Generate' to create your UUIDs. Each one follows RFC 4122 specification ensuring near-zero collision probability — even generating 1 trillion UUIDs per second for 100 years yields less than a 50% chance of any duplicate.
• Copy individual UUIDs or all at once using the copy buttons. Paste directly into database migrations, API request bodies, configuration files, or code comments.

Understanding UUID versions and when to use each

RFC 4122 defines five UUID versions, each optimized for different scenarios. Version 1 generates UUIDs from a timestamp and MAC address — the first 60 bits encode time (in 100-nanosecond intervals since October 15, 1582) and the next 48 bits encode the network interface MAC address. This makes Version 1 UUIDs globally unique but leaks hardware information. Version 4 generates UUIDs entirely from random numbers using cryptographically secure random sources — this is the most common choice for general identifiers because it provides maximum privacy with no predictable patterns. Version 7 (proposed in RFC 9562, widely adopted in 2023+) encodes a Unix timestamp in the first 48 bits followed by random data, making UUIDs sortable by creation time while maintaining uniqueness — ideal for database primary keys where sequential ordering improves B-tree index performance. Version 3 and 5 use MD5 and SHA-1 hashing respectively to create deterministic UUIDs from namespace identifiers and names — useful when you need reproducible identifiers (like generating the same UUID for the string 'users' table every time). Understanding these differences helps you choose the right version for your use case rather than defaulting blindly to Version 4.

Common pitfalls when working with UUIDs in production

• Storage size: A UUID stored as a VARCHAR(36) takes 36 bytes plus overhead, while as raw binary (BINARY(16)) it takes only 16 bytes. In PostgreSQL, use the native UUID type; in MySQL, use BINARY(16) for optimal storage and indexing performance.
• Index fragmentation: Version 4 UUIDs cause severe index fragmentation in B-tree databases because their randomness scatters inserts across the entire index tree. Version 7 UUIDs solve this by being time-sortable, reducing page splits and improving write throughput by up to 10x in high-insert workloads.
• Collision assumptions: While UUID v4 collision probability is astronomically low, it's not zero. The birthday paradox means that after generating approximately 2^64 (18 quintillion) UUIDs, there's a 50% chance of at least one collision. For most applications this is irrelevant, but distributed systems generating billions of IDs daily should consider version 7 or add application-level deduplication.
• Security considerations: Never use UUIDs as security tokens or session identifiers if they're generated with non-cryptographic randomness. Use crypto.randomUUID() (available in Node.js 14.17+ and modern browsers) which leverages the OS's CSPRNG rather than Math.random().