UUID Generator
Generate UUID v4. Click to copy instantly.
-
For a deeper comparison of UUID versions, DB performance impact, and ULID, see the UUID v1 vs v4 vs v7 Guide.
Practical Example
Generate identifiers for test records, mock API responses, or temporary database rows. Bulk generation lets you copy several IDs at once for seed data and migration testing.
What is a UUID?
UUID (Universally Unique Identifier) is a 128-bit identifier standardized by RFC 4122. It is typically represented as a 8-4-4-4-12 hexadecimal string (e.g., 550e8400-e29b-41d4-a716-446655440000), or 32 characters without dashes. UUIDs are used across software development for database primary keys, API request identification, session management, and filename generation.
This tool generates UUID version 4 (v4), which fills 122 bits with random values. The remaining 6 bits are fixed for version information (4) and RFC variant bits. The theoretical collision probability is extremely low (2^122 combinations), making it practically unique for all real-world applications.
All generation happens client-side using Math.random() in your browser. No data is sent to any server.
UUID Version Comparison
UUID v1 is based on timestamp and MAC address. It guarantees chronological ordering but exposes the MAC address, raising privacy concerns.
UUID v4 is purely random. It is simple to generate and contains no personal information, making it the most widely used version. However, the lack of time ordering can impact database index performance.
UUID v7 was standardized in RFC 9562 (2024). It embeds a Unix timestamp (milliseconds) in the upper 48 bits, providing chronological sorting and better B-tree index performance. New projects should consider adopting v7.
Practical Use Cases
Distributed Primary Keys — Generate collision-free IDs across multiple services without central coordination. Unlike auto-increment IDs, no node synchronization is needed.
Session & Tracking Keys — Quickly issue identifiers for shopping carts, temporary sessions, and file uploads for unauthenticated users.
Test Data Generation — Assign consistent unique keys to QA fixtures, preventing test data collisions.
Idempotency Keys — Include a unique UUID per request in API headers to prevent duplicate processing in payment APIs and similar systems.
Storage & Usage Tips
Case Consistency — UUID is case-insensitive per RFC 4122, but string comparisons in databases may fail if mixed. Standardize on lowercase or uppercase across your project.
Dash Format Consistency — Dashed format is 36 characters, dashless is 32. Validation logic may differ, so choose one format and apply it consistently.
Not for Security Tokens — UUIDs are identifiers, not secrets. For authentication tokens or session secrets, use crypto.getRandomValues() or dedicated token libraries.
Database Performance — UUID v4's randomness causes frequent page splits in B-tree indexes. For high-volume INSERT workloads, consider UUID v7 or ULID which include time ordering. In MySQL, storing as BINARY(16) saves space.
How to Read the Output
UUID v4 structure: xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx. The 4 indicates UUID version, and the y position (8, 9, a, or b) represents RFC 4122 variant bits. Checking these two positions validates that a UUID is properly formatted v4.
Should You Actually Worry About Collisions?
UUID v4 carries 122 bits of randomness. Generating a billion per second for a century still would not reach a 50% collision probability, so collision-handling logic is wasted effort. What does matter is generator quality: Math.random()-based generators lack cryptographic randomness and can be predictable, so anything security-sensitive — session tokens, reset codes — should use crypto.randomUUID() or crypto.getRandomValues().
Using UUIDs as Database Primary Keys
Random v4 values scattered across a clustered index (e.g. MySQL InnoDB primary keys) cause frequent page splits and degrading insert performance as tables grow. That pain point is why time-ordered UUID v7 was standardized (RFC 9562, 2024). For new designs, the current practical answer is either v7, or the combination "UUID for external exposure, auto-increment for internal join keys." Version internals and DB benchmarks are in the UUID version comparison guide.
Frequently Asked Questions
How is UUID v4 generated?
128 bits are allocated: 122 filled with random values, 4 bits for version info (0100), and 2 bits for RFC variant (10). This tool uses Math.random() in the browser, producing results instantly with no server communication.
Can I use UUID as a database primary key?
Yes. It's useful for generating collision-free IDs in distributed systems. However, v4's randomness can impact index performance. If ordering matters, consider UUID v7 or ULID. In MySQL, storing as BINARY(16) saves space compared to CHAR(36).
Can I use UUID as a security token?
Not recommended. UUIDs don't guarantee unpredictability, and Math.random()-based implementations are not cryptographically secure. Use crypto.getRandomValues() or server-side token generation for security purposes.
Why is generation capped at 100?
For browser performance and readability. For larger sets, generate multiple batches and use the Copy All button. For regular bulk generation needs, consider CLI tools like uuidgen or programming libraries.
Should I store UUIDs as numbers?
Not recommended. UUIDs are hexadecimal strings. Store as dashless 32-character hex strings or BINARY(16). Converting to integers requires 128-bit integer support, which most languages don't natively provide.
Is generated data sent to a server?
No. All generation and copying happens entirely in your browser. No network requests are made—you can verify this in your browser's DevTools Network tab.
What is the difference between UUID and ULID?
ULID (Universally Unique Lexicographically Sortable Identifier) includes a millisecond timestamp in the upper 48 bits, enabling lexicographic sorting. Similar to UUID v7, but uses Crockford Base32 encoding for a 26-character representation. It's considered as an alternative to UUID v4 where database index performance matters.