UUID Generator — v4 Random, v1 Time-Based, v7 Sortable
Quick Answer
A UUID (Universally Unique Identifier) is a 128-bit number formatted as 8-4-4-4-12 hexadecimal digits, used to identify items across distributed systems. UUIDv4 uses 122 random bits, giving about 5.3 times 10 to the 36 possible values per RFC 4122.
Also searched as: uuid v4 generator, guid generator online, random uuid, unique id generator
How UUID Generation Works
A UUID is a 128-bit integer formatted as 32 hexadecimal digits grouped 8-4-4-4-12 and separated by hyphens. The format is defined by RFC 4122, first published by the IETF in 2005 and updated by RFC 9562 in May 2024, which added UUIDv6, v7, and v8. Within the 128 bits, four bits encode the version number and two or three bits encode the variant (the layout family). The remaining 122 bits carry data specific to the version: a timestamp and node for v1, pseudo-random bits for v4, or a millisecond timestamp prefix followed by random bits for v7. Because the identifier space is so large, clients can mint UUIDs independently on any machine with no coordination, which is why they are the standard for primary keys in distributed databases, message IDs in event streams, and device identifiers in mobile apps. For related randomization needs see our random number generator and password generator.
The UUID Formula and Bit Layout
For UUIDv4 the layout is simple: start with 16 random bytes produced by a cryptographically secure source, then overwrite two specific positions. Byte 6 is masked to keep its low 4 bits and ORed with 0x40 so that the high nibble becomes 4, marking it as version 4. Byte 8 is masked to keep its low 6 bits and ORed with 0x80 so that the top two bits become 10, marking the RFC 4122 variant. The remaining 122 bits stay random. A worked example: the raw bytes {0x55, 0x0e, 0x84, 0x00, 0xe2, 0x9b, 0x11, 0xd4, 0xa7, 0x16, 0x44, 0x66, 0x55, 0x44, 0x00, 0x00} format as 550e8400-e29b-11d4-a716-446655440000, where the 1 after e29b marks v1 and the a in a716 marks the RFC 4122 variant. UUIDv7 replaces the first 48 bits with the current Unix millisecond timestamp, so the resulting IDs sort chronologically when compared as strings or byte arrays.
Key Terms You Should Know
Version: the 4-bit field identifying how the UUID was generated (1, 3, 4, 5, 6, 7, or 8). Variant: the 2 or 3 bits marking which UUID layout family applies; the RFC 4122 variant is 10 in binary. Entropy: the number of unpredictable bits; UUIDv4 has 122. Nil UUID: the special all-zero UUID 00000000-0000-0000-0000-000000000000, reserved as a sentinel. Max UUID: the all-ones ffffffff-ffff-ffff-ffff-ffffffffffff, added in RFC 9562. GUID: Microsoft's name for the same concept; a GUID and a UUID are byte-for-byte identical, though Microsoft historically serialized the first three fields in little-endian byte order. Namespace UUID: a fixed UUID used as a salt when hashing a name into a v3 (MD5) or v5 (SHA-1) UUID, giving deterministic output for the same input.
UUID Versions Compared — Reference Data
Choosing between UUID versions depends on whether you need time-ordering, determinism, or pure randomness. The table below summarizes the differences documented in RFC 9562 and confirmed by the IANA UUID registry. UUIDv4 remains the most common default in web frameworks, but UUIDv7 is the new recommended choice when UUIDs will be used as database primary keys because of its write-performance benefits. UUIDv5 is preferred over v3 whenever determinism is needed, because SHA-1 is stronger than MD5. Vendor-specific variants like Microsoft's sequential GUIDs and Snowflake IDs are related but not standardized by the IETF.
| Version | Source | Random bits | Sortable | Best for |
|---|---|---|---|---|
| v1 | Time + MAC | 14 (clock seq) | Partial | Legacy systems |
| v3 | MD5(namespace+name) | 0 | No | Deterministic IDs |
| v4 | Random | 122 | No | General purpose |
| v5 | SHA-1(namespace+name) | 0 | No | URL-derived IDs |
| v6 | Reordered v1 | 14 | Yes | Time-ordered legacy |
| v7 | Unix ms + random | 74 | Yes | Database keys |
Practical Examples
Example 1 — API request ID: An Express.js middleware calls crypto.randomUUID() to tag every incoming request with a UUIDv4 such as 3f50b6e1-4d1e-4e6a-9c27-8a6c1b44c7de. The ID is added to the response header X-Request-Id and to every structured log entry, so an engineer can trace a single request across 12 microservices by grepping the log warehouse. Example 2 — Primary key with UUIDv7: A Postgres table storing 50 million orders uses UUIDv7 as its primary key. Because the first 48 bits encode the insert timestamp, new rows land at the end of the clustered index, avoiding the page-split penalty that plagues random UUIDv4 inserts. Percona benchmarks from 2023 show sustained insert throughput roughly 3x higher on UUIDv7 than on UUIDv4 for tables above 10 million rows. Example 3 — Deterministic UUIDv5: A content pipeline needs stable IDs for articles keyed by URL. Using the DNS namespace 6ba7b810-9dad-11d1-80b4-00c04fd430c8 and the URL https://example.com/a, UUIDv5 produces the same output a8f8a0b2-... every time, so repeated imports do not create duplicates.
Tips and Best Practices
Prefer crypto.randomUUID(): when your runtime supports it, use the built-in function; it is the fastest and safest option and returns a Type-4 UUID per WHATWG spec. Never use Math.random(): it is not cryptographically secure, can collide, and is a common cause of vulnerabilities in auth tokens. Pick v7 for database keys: time-ordered UUIDs dramatically improve InnoDB and SQL Server clustered-index performance compared to v4. Store as binary, not text: a native UUID column uses 16 bytes versus 36 bytes for the hyphenated string, saving index space. Do not parse the version nibble for security: clients can forge it; validate UUIDs with a regex plus server-side lookup. Include UUIDs in tracing headers: propagate a correlation ID through HTTP headers, Kafka message metadata, and gRPC metadata to make distributed debugging possible. Beware of UUIDv1 privacy leaks: v1 embeds the MAC address of the generating machine; use v4 or v7 whenever the ID is shown to users.
Frequently Asked Questions
What is a UUID?
A UUID (Universally Unique Identifier) is a 128-bit label used to identify information in computer systems without requiring a central authority. Defined by RFC 4122, a UUID is written as 32 hexadecimal digits split into five groups by hyphens (8-4-4-4-12), such as 550e8400-e29b-41d4-a716-446655440000. Because the number of possible UUIDs is about 3.4 times 10 to the 38, collisions are astronomically unlikely even when generated independently. UUIDs are used as database keys, session IDs, file names, and distributed-system identifiers.
What is the difference between UUIDv1, UUIDv4, and UUIDv7?
UUIDv1 combines a 60-bit timestamp with a node ID derived from the MAC address, making the UUID time-ordered but leaking the generator's hardware identity. UUIDv4 uses 122 random bits and 6 fixed bits, providing about 5.3 times 10 to the 36 possible values with no ordering. UUIDv7, introduced in RFC 9562 in 2024, starts with a 48-bit Unix millisecond timestamp followed by random bits, giving UUIDs that are both globally unique and sortable by creation time, which is ideal for database primary keys.
How do I generate a UUID in JavaScript?
Modern browsers and Node.js 19 or newer expose crypto.randomUUID(), which returns a cryptographically secure RFC 4122 UUIDv4 string. For older environments you can call crypto.getRandomValues on a 16-byte Uint8Array, then set byte 6 to (bytes[6] and 0x0f) or 0x40 for version 4 and byte 8 to (bytes[8] and 0x3f) or 0x80 for the RFC 4122 variant. Format the 16 bytes as hexadecimal with hyphens after positions 4, 6, 8, and 10. This generator uses that exact algorithm in the browser.
How many UUIDs can I generate before a collision?
With UUIDv4, you would need to generate roughly 2.71 quintillion UUIDs to have a 50 percent chance of a single collision, according to the birthday problem applied to 122 random bits. In practical terms, a service generating one billion UUIDv4 values per second for 85 years has about a one in a billion chance of a duplicate. This is why RFC 4122 states that UUIDs can be created without significant central coordination. For even higher uniqueness guarantees, pair UUIDs with a namespace or prefix.
Are UUIDs secure enough to use as session tokens?
Only UUIDs generated from a cryptographically secure random source, such as crypto.getRandomValues, are acceptable as session tokens. OWASP recommends at least 128 bits of entropy for session identifiers, and a properly generated UUIDv4 has 122 random bits, which meets the threshold. Do not use UUIDv1 for security contexts, because its timestamp and MAC structure can be predicted or used to fingerprint the generating machine. When in doubt, use a dedicated token library that emits 256 bits of entropy.
Can I use UUIDs as primary keys in a database?
Yes, UUIDs work as primary keys, but UUIDv4 can hurt write performance on clustered indexes because inserts land in random positions, causing B-tree page splits. Postgres, MySQL, and SQL Server all support a native UUID or UNIQUEIDENTIFIER column type. For high-write tables, prefer UUIDv7 or a time-sortable variant so that newly inserted rows cluster at the end of the index. Benchmarks published by Percona in 2023 show UUIDv7 inserts can be 2 to 10 times faster than UUIDv4 on InnoDB.