UUID Generator
Generate and validate UUID v4, UUID v7, and ULID identifiers with timestamp extraction.
Press Ctrl+Enter (Cmd+Enter on Mac) to generate
About UUID Generator
A Universally Unique Identifier (UUID) is a 128-bit value designed to be globally unique without requiring a central registration authority. Standardized by RFC 9562 (which supersedes the original RFC 4122), UUIDs are formatted as 32 hexadecimal digits displayed in five groups separated by hyphens: 8-4-4-4-12, such as 550e8400-e29b-41d4-a716-446655440000. The version nibble (the 13th hex digit) indicates the UUID generation algorithm, and the variant bits (the 17th hex digit) identify the UUID layout. UUIDs are one of the most widely used mechanisms for generating unique identifiers in distributed systems because they can be created independently on any machine at any time with a negligible probability of collision.
Several UUID versions exist, each serving different needs. Version 4 (UUIDv4) is the most commonly used and generates identifiers from 122 bits of cryptographically secure random data, providing approximately 5.3 x 10^36 possible values. Version 7 (UUIDv7) is a newer format introduced in RFC 9562 that embeds a Unix timestamp in the most significant 48 bits, followed by random data. This makes UUIDv7 values roughly sortable by creation time, which significantly improves database index performance compared to the fully random UUIDv4. ULIDs (Universally Unique Lexicographically Sortable Identifiers) are a related concept that also combines a timestamp with randomness but uses a different encoding (Crockford's Base32) to produce a 26-character string that is both shorter and case-insensitive.
This tool generates UUIDv4, UUIDv7, and ULID identifiers using cryptographically secure randomness provided by your browser's Web Crypto API. You can generate single identifiers or bulk-generate multiple values at once. Whether you need a primary key for a database row, a correlation ID for distributed tracing, an idempotency key for an API request, or a session token for a web application, this tool produces standards-compliant identifiers ready for immediate use.
How to Use the UUID Generator
- Select the identifier format you need: UUIDv4 (random), UUIDv7 (timestamp + random), or ULID (lexicographically sortable, Crockford Base32 encoding).
- Click the 'Generate' button to produce a new identifier. The result appears instantly in the output field.
- To generate multiple identifiers at once, specify the desired quantity (e.g., 10, 50, or 100) in the bulk generation field and click 'Generate Bulk'. Each identifier is guaranteed to be unique.
- Copy individual identifiers to your clipboard with the copy button, or copy the entire bulk list for use in scripts, seed data, or test fixtures.
- For UUIDv7 and ULID, note that the embedded timestamp reflects the moment of generation. If you generate multiple values in the same millisecond, the random portion ensures uniqueness while the timestamp portion remains the same.
- Use the generated identifiers directly as database primary keys, API request IDs, file names, or any other context where a globally unique, collision-resistant identifier is needed.
Common Use Cases
Database Primary Keys
UUIDs are widely used as primary keys in relational and NoSQL databases, especially in distributed systems where auto-incrementing integers are impractical because multiple nodes insert records concurrently. UUIDv7 is particularly well-suited for this use case because its time-ordered nature produces monotonically increasing values that maintain B-tree index efficiency, avoiding the random insertion pattern of UUIDv4 that causes index fragmentation and page splits in databases like PostgreSQL and MySQL.
Distributed Tracing and Correlation IDs
In microservice architectures, a single user request may traverse dozens of services. Assigning a UUID as a correlation ID at the entry point and propagating it through all downstream calls creates a unified trace that can be searched across centralized logging systems. This makes debugging production issues dramatically faster. The W3C Trace Context standard uses a similar format for its trace-id field.
Idempotency Keys for API Requests
Payment processors like Stripe require an idempotency key with each request to ensure that retrying a failed network call does not result in duplicate charges. Generating a UUIDv4 for each logical operation and including it as the idempotency key guarantees that the server can detect and deduplicate retried requests, even across different client instances.
Secure Session and Token Identifiers
Session IDs, password reset tokens, and email verification tokens must be unpredictable to prevent attackers from guessing valid values. UUIDv4 generated from a cryptographically secure random source provides 122 bits of entropy, making brute-force guessing computationally infeasible. This exceeds the OWASP recommendation of at least 128 bits of entropy for session identifiers when combined with other random components.
Frequently Asked Questions
Can two UUID v4 values ever collide?
Theoretically, yes -- but the probability is so astronomically low that it is effectively impossible in practice. UUIDv4 has 122 random bits, yielding approximately 5.3 x 10^36 possible values. By the birthday paradox, you would need to generate about 2.7 x 10^18 (2.7 quintillion) UUIDs before reaching a 50% probability of a single collision. To put that in perspective, if you generated one billion UUIDs per second, it would take approximately 86 years to reach that threshold. For all practical purposes, UUIDv4 collisions do not happen.
When should I use UUIDv7 instead of UUIDv4?
Use UUIDv7 when the identifiers will be stored as primary keys or indexed columns in a database. Because UUIDv7 values are roughly time-ordered, they produce sequential inserts that keep B-tree indexes efficient. UUIDv4, being fully random, causes random insertions that lead to index fragmentation, increased page splits, and degraded write performance over time. UUIDv7 also embeds a timestamp, which can be useful for approximate creation-time ordering without requiring an additional column. Use UUIDv4 when you need maximum unpredictability and have no database indexing concerns.
What is a ULID and how does it differ from a UUID?
A ULID (Universally Unique Lexicographically Sortable Identifier) is a 128-bit identifier that, like UUIDv7, combines a timestamp with randomness. The key differences are encoding and sortability: ULIDs are encoded using Crockford's Base32, producing a 26-character string (compared to the 36-character UUID format), and they are designed to sort lexicographically in time order. ULIDs do not follow the UUID bit layout and are not formally a UUID version. They are popular in applications where shorter identifiers and string sorting are desirable.
Should I use UUIDs or auto-incrementing integers as primary keys?
Both approaches have trade-offs. Auto-incrementing integers are smaller (4-8 bytes vs. 16 bytes), produce naturally ordered inserts, and are human-readable. However, they require a centralized sequence generator, leak information about record counts and creation order, and are difficult to use across distributed databases. UUIDs can be generated anywhere without coordination, reveal no business information, and work naturally in distributed systems. The performance gap between UUIDv7 (time-ordered) and integers is small in modern databases. For most web applications and microservices, UUIDv7 offers the best balance of performance and distributed-system friendliness.
Is it safe to expose UUIDs in URLs or APIs?
UUIDv4 values are safe to expose because they are generated from cryptographically secure randomness and are not guessable. However, UUIDv7 and ULIDs embed a timestamp, which reveals when the record was created. Additionally, no UUID version should be relied upon as the sole access control mechanism -- always implement proper authorization checks. An attacker should not be able to access a resource simply by knowing its UUID; the server must verify that the requesting user has permission to access it.
How do I store UUIDs efficiently in a database?
The most storage-efficient option is to store UUIDs as a native 16-byte binary type (BINARY(16) in MySQL, BYTEA in PostgreSQL, or the native UUID type in PostgreSQL). Storing them as a 36-character string (CHAR(36) or VARCHAR(36)) uses more than twice the space and produces slower comparisons. PostgreSQL's native uuid type is the best option if you use PostgreSQL, as it stores 16 bytes and supports efficient indexing. If you must use a string representation, omit the hyphens to save 4 bytes per row (32 characters instead of 36).