Skip to content
DevToolKit

UUID Generator

Generate UUID v4 and v7 identifiers online for free. RFC 9562 compliant with bulk generation support. All processing happens in your browser, no data uploaded.

Type
Count
Nil UUID00000000-0000-0000-0000-000000000000
Max UUIDffffffff-ffff-ffff-ffff-ffffffffffff
UUID Decoder
UUID Validator

Which version to use?

v4 (random) is the most common choice for general-purpose unique identifiers. v7 (time-ordered, RFC 9562) is ideal for database primary keys as it preserves chronological ordering. v1 embeds a timestamp with a random node (browsers cannot expose MAC addresses). v5 is deterministic: the same namespace+name always produces the same UUID. ULID offers lexicographic sorting with Crockford Base32 encoding. NanoID provides shorter, URL-safe IDs with configurable length.

Was this tool helpful?

How to Use

Generating universally unique identifiers is essential for distributed systems, database design, and application development. This free online UUID generator creates RFC 9562 compliant v4 and v7 identifiers directly in your browser. Follow these steps:

  1. Select the UUID version — Choose UUID v4 for random identifiers or UUID v7 for time-ordered identifiers. Each version serves different use cases explained in the About section below.
  2. Set the quantity — Specify how many UUIDs to generate. The tool supports bulk generation for scenarios where you need multiple identifiers at once, such as seeding a database or preparing test fixtures.
  3. Click Generate — The tool creates the specified number of UUIDs instantly using the browser's cryptographic random number generator (crypto.getRandomValues()).
  4. Copy the results — Click the copy button to copy all generated UUIDs to your clipboard. Each UUID appears on its own line for easy pasting into code, SQL statements, or configuration files.

UUID Format

All UUIDs follow the standard 8-4-4-4-12 hexadecimal format, such as 550e8400-e29b-41d4-a716-446655440000. The 13th character always indicates the version (4 for v4, 7 for v7), and the 17th character is always 8, 9, a, or b (indicating the RFC 9562 variant). This consistent format makes UUIDs easy to identify and validate in any codebase.

  • UUID v4 example: f47ac10b-58cc-4372-a567-0e02b2c3d479 — note the 4 in position 13.
  • UUID v7 example: 018ec7a4-2d3b-71f0-b3c2-9f4e1a8d6b0c — note the 7 in position 13 and the time-based prefix.

About This Tool

A Universally Unique Identifier (UUID) is a 128-bit label used to identify information in computer systems without requiring a central coordinating authority. Originally defined in RFC 4122 (2005) and updated by RFC 9562 (May 2024), UUIDs are designed so that any system can independently generate identifiers with a negligible probability of duplication. As of 2026, UUIDs are used as primary keys in databases, correlation IDs in distributed tracing, session identifiers in web applications, and resource identifiers in REST APIs.

The UUID specification defines 128 bits organized as 32 hexadecimal digits displayed in five groups separated by hyphens (8-4-4-4-12). Of these 128 bits, 4 bits encode the version and 2 bits encode the variant, leaving 122 bits for version-specific content. The version field (bits 48-51) identifies how the UUID was generated, and the variant field (bits 64-65) is always set to the binary value 10, indicating an RFC 9562 UUID.

UUID Version 4: Random

UUID v4 is the most widely deployed UUID version. It fills all 122 available bits with cryptographically secure random data, generated by crypto.getRandomValues() in browsers or crypto.randomUUID() in modern environments. The pure randomness of v4 means there is no temporal or spatial information embedded in the identifier, providing maximum privacy. However, this randomness also means v4 UUIDs are not sortable, which can cause performance problems when used as database primary keys in B-tree indexed tables.

UUID Version 7: Time-Ordered

UUID v7, formally standardized in RFC 9562, addresses the database performance issue by embedding a Unix timestamp in millisecond precision in the first 48 bits. The remaining 74 bits (after version and variant) are filled with random data. This design produces UUIDs that sort chronologically when compared lexicographically, which dramatically reduces B-tree page splits during insertion. Benchmarks show that UUID v7 primary keys can improve database write performance by 2-10x compared to random UUID v4 keys, depending on the database engine and workload.

The time-ordering property of UUID v7 also makes identifiers useful for rough chronological sorting without an additional timestamp column. Note that the embedded timestamp reveals approximately when the UUID was generated, which may be undesirable in privacy-sensitive contexts. For applications requiring both temporal ordering and timestamp privacy, consider encrypting or hashing the time component separately.

UUIDs vs Other Identifier Formats

Several alternative identifier formats exist alongside UUIDs. Auto-incrementing integers are the simplest option but reveal record counts, lack portability across systems, and require central coordination. Twitter's Snowflake IDs (64-bit, time-ordered) are compact but require machine ID assignment. Stripe-style prefixed IDs (like cus_N4e9bLhYFi) are human-friendly but non-standard. NanoID provides shorter random strings but without the standardized structure and collision guarantees of UUIDs. For most applications, UUID v7 offers the best combination of uniqueness, sortability, and standardization.

Why Use This Tool

UUID generation is a fundamental requirement in modern software architecture. From microservices to mobile applications, unique identifiers enable independent systems to create and reference resources without coordination. Here are the primary use cases for UUID generation:

  • Database primary keys — UUIDs allow multiple application instances, microservices, or database shards to generate primary keys independently without collision risk. UUID v7 is particularly well-suited because its time-ordering property maintains B-tree index efficiency, avoiding the fragmentation caused by random v4 UUIDs.
  • Distributed system identifiers — In event-driven architectures, message queues, and distributed tracing, UUIDs serve as correlation IDs that link related operations across service boundaries. Tools like Jaeger, Zipkin, and OpenTelemetry use UUIDs extensively for trace and span identification.
  • API resource identifiers — REST APIs use UUIDs in URL paths (e.g., /api/users/550e8400-e29b-41d4-a716-446655440000) because they are globally unique, do not expose sequential information, and are portable across environments and databases.
  • Testing and development — Developers frequently need to generate UUIDs for test data, seed scripts, mock API responses, and database fixtures. Bulk generation is especially useful when preparing large test datasets.
  • Session and token management — Web applications use UUIDs for session identifiers, CSRF tokens, invitation codes, and password reset tokens. The cryptographic randomness of UUID v4 ensures these tokens are unpredictable and resistant to brute-force guessing.

Privacy and Security

This UUID generator runs entirely in your browser using crypto.getRandomValues() for cryptographically secure random number generation. No UUIDs are transmitted to any server, stored in any database, or logged by any system. The generated identifiers exist only in your browser until you copy them.

FAQ

What is the difference between UUID v4 and UUID v7?
UUID v4 is entirely random, generated from 122 bits of cryptographic randomness. UUID v7 embeds a Unix timestamp in the first 48 bits followed by random data, making v7 identifiers time-sortable. UUID v7 was standardized in RFC 9562 (May 2024) and is recommended for database primary keys because its time-ordered nature improves B-tree index performance.
What is the probability of a UUID collision?
For UUID v4 with 122 random bits, the probability of collision is astronomically low. You would need to generate approximately 2.71 quintillion (2.71 x 10^18) UUIDs to have a 50% chance of a single collision. In practical terms, generating 1 billion UUIDs per second for 85 years would give you only a 50% chance of one collision.
Should I use UUID v4 or UUID v7 for database primary keys?
UUID v7 is the better choice for database primary keys. Because v7 UUIDs are time-ordered, they cause far fewer B-tree page splits than random v4 UUIDs during insertion. PostgreSQL, MySQL, and other databases see significantly better write performance with ordered keys. UUID v4 is still preferred when you need identifiers with no embedded temporal information.
What does RFC 9562 define?
RFC 9562, published in May 2024, obsoletes RFC 4122 and standardizes UUID versions 1-8. It formally defines UUID v7 (time-ordered with random) and UUID v8 (custom/experimental). The RFC also clarifies the UUID format as 128 bits with a 4-bit version field and a 2-bit variant field, leaving 122 bits for version-specific data.