UUID & GUID Generator Online
Generate random UUID v4 or time-ordered UUID v7 identifiers. Fully compliant with RFC 4122 and RFC 9562 standards.
In modern software design, generating unique identifiers is a critical task. Whether you are indexing database rows, tagging user sessions, or naming uploaded files, systems require identifiers that can be generated independently without communicating with a central database. Standard incremental integer keys (like 1, 2, 3) fail in distributed networks because multiple nodes cannot sync sequences without latency. Universally Unique Identifiers (UUIDs) solve this, providing a 128-bit space that guarantees uniqueness without centralization.
The Structure of UUID v4
UUID v4 is defined in RFC 4122. It is built entirely on random numbers. Out of the 128 bits in the structure, 6 bits are reserved to indicate the version (binary 0100 for 4) and variant (binary 10 for RFC compliance). The remaining 122 bits contain cryptographically secure random values. This produces a huge number of possible keys, making the chance of a collision virtually zero. This randomness is ideal for temporary tokens, session keys, and keys where creation order does not matter.
The Rise of UUID v7 in Database Design
Despite the benefits of UUID v4, its random nature causes performance issues when used as a primary key in database tables. Databases like MySQL, PostgreSQL, and SQL Server organize records using clustered indexes sorted by the primary key. When a random UUID v4 is inserted, the B-tree index is forced to split pages to write the new record. This causes disk thrashing and degrades performance. UUID v7 (formally standardized in RFC 9562 in 2024) solves this by placing a Unix timestamp in the first 48 bits, followed by version and variant bits and 74 random bits. This sequential timestamp ensures that new records are appended chronologically, keeping index updates fast and efficient.
UUID Layout Specification
A standard UUID is formatted as a 36-character string consisting of 32 hexadecimal digits separated by four hyphens:
f81d4fae-7dec-11d0-a765-00a0c91e6bf6 xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
The M position indicates the version digit (e.g., 4 or 7), while the N position represents the variant digit (typically 8, 9, a, or b). Generating UUIDs client-side using secure browser entropy ensures high performance and security.
frequently asked questions
UUID v4 is entirely random (except for version and variant bits), providing 122 bits of entropy. UUID v7 is time-ordered, combining a 48-bit Unix millisecond timestamp with 74 random bits. UUID v7 is preferred for database primary keys because its sequential nature improves index insert performance and page allocation.
Yes. The total space of possible UUIDs is 2^128 (approximately 3.4 x 10^38). The probability of a collision in UUID v4 is so low that generating billions of IDs every second for a century would result in a negligible chance of duplicates, making them safe for distributed systems.
Because UUID v7 begins with a timestamp, IDs generated later will have a higher numeric value than those generated earlier. This makes them sortable by creation time. Standard UUID v4 values are random, which causes database B-trees to re-index, degrading database write performance.
GUID (Globally Unique Identifier) is Microsoft's terminology for a implementation of the UUID standard. Practically, a GUID is a 128-bit UUID, and the terms are used interchangeably in modern software development.
Yes. The random entropy is generated client-side using the browser's cryptographically secure pseudo-random number generator (crypto.getRandomValues), which meets high security standards. No keys are sent to any server.