UUID Generator Version 4 (V4)
Shortcuts: C copy · R new uuid · G generate bulk
UUID v4 generates values in your browser using a cryptographically secure random source. A UUID v4 is a 128-bit identifier from RFC 9562, built from 122 random bits and 6 fixed bits for the version and variant. Watch each field highlight as you generate, then create one or up to 1,000 in five formats and copy them. Free, with no sign-up and nothing sent to a server.
UUID v4 Example
UUID v4 is a 128-bit identifier made almost entirely of random data. It is written as 32 hexadecimal digits in five groups separated by hyphens.
A generator fills 122 of the 128 bits with random values, then sets the remaining 6 bits: 4 for the version and 2 for the variant, as defined in RFC 9562. No clock, MAC address, or name is involved, so the value reveals nothing about when or where it was created.
Our tool takes those random bits from crypto.getRandomValues, the secure random generator built into your browser, and highlights each part of the result.
Because any device can generate one on its own, without a central server, UUID v4 is commonly used for:
- Database primary keys
- API resource IDs
- Request, session, and idempotency keys
- Test and sample data
UUID v4 Example
A UUID v4 is a 128-bit identifier written as 32 hexadecimal digits in five groups. Below is a real example and how to read it.
Example UUID v4
550e8400-e29b-41d4-a716-446655440000
This is a valid UUID v4. The 4 at the start of the third group marks the version, and the a at the start of the fourth group is a variant digit. The remaining digits are random.
The same value looks different depending on the format you choose in the tool:
|
Style |
Example |
|---|---|
|
Standard |
|
|
Uppercase |
|
|
Braces |
|
|
URN |
|
Generate a new one in the tool above and the bit breakdown shows which bits are random and which are fixed.
UUID v4 Format
A UUID v4 uses the 8-4-4-4-12 layout: 32 hex digits plus 4 hyphens, 36 characters in total. The general pattern is:
xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx
Here 4 is the version, and y is the variant digit, which is always 8, 9, a or b.
|
Group |
Example |
Meaning |
|---|---|---|
|
1 (8 digits) |
|
Random |
|
2 (4 digits) |
|
Random |
|
3 (4 digits) |
|
First digit |
|
4 (4 digits) |
|
First digit |
|
5 (12 digits) |
|
Random |
Six of the 128 bits are fixed for the version and variant. The other 122 bits are random.
How to Identify a UUID v4
Check two positions:
- The first digit of the third group must be
4. - The first digit of the fourth group must be
8,9,aorb.
In 550e8400-e29b-41d4-a716-446655440000, the third group starts with 4 and the fourth with a, so it passes both checks.
A matching pattern shows only that the value is formatted as a v4. It does not prove the value was generated randomly. To check any UUID quickly, use the UUID Version Checker.
How Does UUID v4 Work?
A standard UUID v4 has 128 bits. Six of them are fixed to mark the version and variant, and the other 122 are random. Generate one in the tool above and the live bit breakdown colour-codes each part.
128-Bit UUID Structure
RFC 9562 defines UUID v4 as a 128-bit value written as 32 hex digits in the 8-4-4-4-12 layout. Unlike v1 or v7, it carries no timestamp, node ID or counter.
| Field | Bits | Value |
|---|---|---|
| random_a | 48 | Random |
| ver | 4 | Fixed: 0100 (version 4) |
| random_b | 12 | Random |
| var | 2 | Fixed: 10 (RFC variant) |
| random_c | 62 | Random |
UUID v4 has no time or node field to reorder, so the byte order option is disabled in this tool and the standard RFC 9562 byte order is used.
Random Bits
122 of the 128 bits are random, spread across three fields (48 + 12 + 62). They are the only part that changes from one UUID v4 to the next.
RFC 9562 says the random bits can come from a random or pseudorandom source, and recommends a cryptographically secure one. This tool uses crypto.getRandomValues() in your browser, a cryptographically secure random generator, and nothing is sent to a server.
Version 4 Bits
The version takes 4 bits, which are always 0100, or 4 in hex. They sit at the start of the third group, so every UUID v4 looks like xxxxxxxx-xxxx-4xxx-xxxx-xxxxxxxxxxxx.
In 550e8400-e29b-41d4-a716-446655440000, the third group 41d4 starts with 4. This is the digit that tells a parser it is looking at a version 4 UUID.
Variant Bits
The variant takes 2 bits, always 10. This marks the UUID as following the RFC 9562 layout (the same one RFC 4122 used).
The two bits sit at the start of the fourth group, with the next two bits random. That makes the first digit of that group 8, 9, a or b. In the example, a716 starts with a (1010), so the variant bits are 10.
Is UUID v4 Random?
Yes. Almost every bit of a UUID v4 is random, except the fixed version and variant bits. But “random” can mean two different things, and the quality of the source decides how reliable the UUID is.
Cryptographically Secure Randomness
A cryptographically secure random number generator (CSPRNG) is built so that its output cannot be predicted, even by someone who has seen earlier values. Operating systems seed it from unpredictable system entropy.
This generator uses crypto.getRandomValues(), the Web Crypto API built into your browser. That is a CSPRNG, so each UUID v4 here comes from a cryptographically secure source, not from Math.random().
Random vs Pseudorandom UUIDs
All computer-generated randomness is technically pseudorandom, because an algorithm produces it. The difference is how predictable that algorithm is.
| Source | Predictable? | Typical use |
|---|---|---|
Math.random() and similar general-purpose generators | Yes, in principle, if the internal state is known | Games, shuffling, non-critical values |
CSPRNG (crypto.getRandomValues(), OS random APIs) | No, by design | Identifiers, keys, tokens |
Both can output a string that looks like a valid UUID v4. Only the second kind gives values that are hard to guess.
Why a Secure Random Source Matters
A weak generator can repeat values or let someone work out the next one from earlier ones. Two machines that start from the same seed can even produce the same “random” UUIDs.
A secure source avoids this, and RFC 9562 recommends it for UUID v4. When you generate UUIDs in your own code, use the language’s secure random API and avoid the basic random function.
Is UUID v4 Unique?
In practice, yes. A UUID v4 is random, not checked against a central list, so uniqueness is a matter of probability and not an absolute guarantee. The odds of a repeat are so small that systems rely on them every day.
UUID v4 Collision Probability
A collision means two UUIDs come out identical. With 122 random bits there are about 5.3 × 10³⁶ possible values, so a clash is extremely unlikely.
A simple way to see it: picture a lottery with 5.3 undecillion tickets, where each draw picks one ticket at random. You would have to draw an enormous number of tickets before two matched.
| UUIDs generated | Chance of at least one duplicate |
|---|---|
| About 103 trillion | About 1 in a billion |
| About 2.71 quintillion | About 50% |
To reach the 50% mark, you would need to generate one billion UUIDs every second for roughly 85 years.
Can Two UUID v4 Values Be the Same?
Yes, in theory. Nothing in the format prevents it, and the probability is never exactly zero. That is why this page does not call UUID v4 100% unique.
Real-world duplicates almost always come from a flawed setup, not from bad luck. A weak random generator, a reused seed or a copied value can all produce repeats. A secure source like the one described above keeps the risk at the mathematical level.
How Many UUID v4 Values Can Be Generated?
There are 2¹²² possible UUID v4 values, about 5.3 undecillion (5.3 × 10³⁶). That is more than a billion billion billion for every person alive today, so running out of values is not a practical concern.
The generator above can create up to 1,000 UUID v4 values in one batch, and you can generate as many batches as you need.
Why Use UUID v4?
UUID v4 is popular because it is simple. Any system can create one on its own, with no setup, no coordination and no lookup. That makes it a safe default when you just need a unique ID.
Random Identifiers
A UUID v4 carries no timestamp, machine ID or counter, so it reveals nothing about when or where it was created. The value is only an identifier.
This also keeps the format easy to work with. It is the same 36-character string in every language and system, and you can switch between standard, URN, Base64 or hex formats in the tool when a system expects something different.
Distributed Applications
In a distributed system, several servers, services or devices may need to create IDs at the same time. With auto-increment numbers, they would have to ask one central source for each new ID.
With UUID v4, each node generates its own ID locally and moves on. The IDs can be created offline, on a phone or in a browser, and merged later without clashes in practice.
Database Records
UUID v4 works well for records that need an ID before they are saved, such as an order created in the app and written to the database later. The ID is known immediately, so related records can reference it right away.
It also avoids exposing record counts. A URL like /users/4812 tells outsiders roughly how many users exist, while a UUID does not. Index behaviour is a separate topic, covered in the databases section below.
API Resources and Test Data
APIs often use UUID v4 as the public ID for resources like users, files or invoices. The IDs are hard to guess one by one and give no hint about how many resources exist.
For test data and mock records, UUID v4 is just as useful. You can generate up to 1,000 values in one batch with the tool above, then copy them or download them as .txt, .csv, .json or .sql.
UUID v4 vs UUID v7
UUID v4 is fully random and carries no timestamp. UUID v7 starts with a timestamp, so its values sort roughly by creation time. Both are 128-bit and defined in RFC 9562, and the tool above generates either one.
UUID v4 vs UUID v7: Key Differences
| UUID v4 | UUID v7 | |
|---|---|---|
| Main design | Random | Time-ordered |
| Timestamp | None | 48-bit Unix timestamp in milliseconds |
| Random data | 122 bits | 74 bits |
| Time ordering | No | Yes, by millisecond |
| Database use | Inserts land in random positions | Inserts land near the end of the index |
| Timestamp exposure | Reveals nothing about creation time | Reveals approximate creation time |
| Common use | General-purpose identifiers | Time-ordered identifiers |
The difference comes from the layout. v4 fills almost all 128 bits with random data, while v7 spends its first 48 bits on the timestamp and keeps the rest for random or optional monotonic data.
Ordering has limits. Two v7 values created in the same millisecond are not guaranteed to sort in creation order unless the generator adds monotonic handling, which RFC 9562 allows but does not require.
Which One Should You Choose?
Choose UUID v4 when you only need a unique ID and do not want it to reveal anything. It suits public IDs, tokens-style references, test data and any case where sorting by creation time does not matter.
Choose UUID v7 when records are stored in a database and you often read or sort them by creation time. Its time-ordered prefix tends to work better with indexes than random values, though the effect depends on your database and workload.
UUID v4 vs UUID v1
UUID v1 is built from a timestamp and a node identifier, while UUID v4 is built from random bits. Both are 128-bit and share the same 8-4-4-4-12 layout, but they are made in very different ways.
Random vs Time-Based Identifiers
UUID v1 combines a 60-bit timestamp, a 14-bit clock sequence and a 48-bit node ID. The timestamp counts 100-nanosecond intervals since 15 October 1582, and the node ID was traditionally the machine’s MAC address. UUID v4 uses 122 random bits
UUID v4 vs UUID v1 — Comparison Table
| UUID v4 | UUID v1 | |
|---|---|---|
| Main design | Random | Time-based |
| Timestamp | None | 60-bit, 100-nanosecond precision |
| Node or machine data | None | 48-bit node ID |
| Uniqueness comes from | Random bits | Timestamp, clock sequence and node ID |
| Sorts by creation time | No | Not directly, because the low part of the timestamp comes first |
In both cases uniqueness is probabilistic in practice, though v1 makes repeats less likely on a single machine because the timestamp keeps moving forward.
Privacy and Timestamp Differences
A UUID v1 exposes the moment it was created, and the timestamp can be decoded from the value. If the node ID is a real MAC address, it also points to the machine that generated it.
RFC 9562 allows a random node ID in place of the MAC address, which removes the hardware link. The creation time still stays visible. UUID v4 shows neither, because it contains no time or machine data.
Which Version Is Better for Your Use Case?
When to Use UUID v4
Choose UUID v4 for general-purpose IDs where you want nothing embedded in the value. It is the simpler and more private choice, and it is what most new projects use.
When to Use UUID v1
Choose UUID v1 only when you must work with an existing system that already depends on it, or when you need to read a creation time from the ID. For new time-ordered IDs, RFC 9562 recommends UUID v7 over v1 unless legacy compatibility is required.
Is UUID v4 Secure?
UUID v4 is hard to guess when it is generated from a secure random source, but it was designed as an identifier, not as a security feature. Secure generation does not make every use of it secure.
UUID v4 and Unpredictability
A UUID v4 has 122 random bits, so guessing one by chance is practically impossible. This is true only when those bits come from a cryptographically secure source, like the crypto.getRandomValues() call this tool uses.
Unpredictability depends on the implementation. A UUID made with a weak generator can still look valid while being easy to predict, so the format alone tells you nothing about how it was created.
Can UUID v4 Be Used as a Secret Token?
It is better not to. RFC 9562 does not promise that every UUID is unguessable, and a UUID’s job is to identify a record, not to prove who is asking. Many libraries also generate UUIDs in ways that were never reviewed as security-grade.
Other risks come from how UUIDs are used. They often appear in URLs, logs, analytics and error reports, so a value that was meant to be secret can leak. Treat a UUID as a name, not as a password.
UUIDs vs Authentication Tokens
| UUID v4 | Authentication token | |
|---|---|---|
| Purpose | Identify a record | Prove access or identity |
| Generated by | Any UUID library | A secure token or session library |
| Expiry and revocation | Not part of the format | Built in or enforced by the system |
| Safe to expose in URLs and logs | Usually | Treat as sensitive |
Using a UUID v4 as a public ID is fine. Relying on it alone to protect access to data is not, and each request should still be checked for permission.
UUID v4 for Databases
UUID v4 works as a database ID, and many systems use it every day. How it affects performance depends on the database engine, the table size and how the data is written, so it needs a closer look than “good” or “bad”.
UUID v4 as a Primary Key
A UUID v4 can be created by the application before the row is saved, so IDs never have to come from the database. This helps with offline creation, data merging and systems with several writers.
Storage matters. A UUID is 16 bytes in a native type (such as PostgreSQL’s uuid) or in BINARY(16). Stored as a 36-character string, it takes more than twice the space, and every index that includes it grows with it.
UUID v4 and Database Indexes
Most database indexes are B-trees that keep keys in sorted order. Because UUID v4 values are random, new rows land in random places in the index instead of at the end.
Whether this hurts depends on the setup:
| Factor | What changes |
|---|---|
| Table size | Small tables fit in memory, so the effect is usually negligible |
| Engine and storage design | Engines that store rows in primary key order (a clustered index) feel random inserts more than engines that keep the table separate from the index |
| Write rate | Heavy insert loads can cause more page splits and a more fragmented index |
| Secondary indexes | In some engines, they store a copy of the primary key, so a larger key makes them larger too |
Measure on your own database with realistic data. General claims like “UUIDs are slow” skip these differences.
UUID v4 vs UUID v7 for Databases
UUID v7 starts with a timestamp, so new values mostly land near the end of the index. For write-heavy tables with ordered storage, this can reduce page splits and scattered writes compared with random v4 values.
That does not make v7 the right choice everywhere. If your table is small, your reads dominate, or you do not want creation time visible in the ID, v4 remains a good option. The general comparison is in the UUID v4 vs UUID v7 section above.
UUID v4 and RFC 9562
UUID v4 is defined by RFC 9562, the current UUID standard published by the IETF. The official text is available at the RFC Editor: RFC 9562: Universally Unique IDentifiers (UUIDs).
UUID v4 Standard
RFC 9562 describes UUID v4 in Section 5.4. It specifies a 128-bit value made of random data, with 4 bits set to the version (0100) and 2 bits set to the variant (10). The remaining 122 bits are random or pseudorandom.
| Field | Bits | Value |
|---|---|---|
| random_a | 48 | Random |
| ver | 4 | 0100 |
| random_b | 12 | Random |
| var | 2 | 10 |
| random_c | 62 | Random |
The RFC also recommends a cryptographically secure source for the random bits. This is the same layout explained step by step in the “How Does UUID v4 Work?” section above.
RFC 4122 and RFC 9562
RFC 4122 was the original UUID standard, published in 2005, and it defined UUID v4 in Section 4.4. RFC 9562 was published in May 2024, replaces RFC 4122 and adds new versions (v6, v7 and v8).
UUID v4 itself did not change. A UUID v4 generated under RFC 4122 is still a valid UUID v4 under RFC 9562. If you see older documentation that cites RFC 4122, the v4 format it describes is the same.
UUID v4 in Programming Languages
Most languages can generate a UUID v4 in one line. Each example below uses a secure random source, and the output is a different UUID every time.
JavaScript
Modern browsers and Node.js have a built-in method that uses a cryptographically secure generator. In browsers it works only in secure contexts (HTTPS or localhost).
javascript
const id = crypto.randomUUID();
console.log(id); // e.g. 3b241101-e2bb-4255-8caf-4136c566a962In Node.js, import it first with const { randomUUID } = require("crypto"); if crypto is not available as a global in your version. (Link: JavaScript UUID v4 guide.)
Python
Python’s standard library includes the uuid module, so no install is needed. uuid4() takes its random bits from the operating system’s secure source.
import uuid
import uuid
print(uuid.uuid4()) # e.g. 3b241101-e2bb-4255-8caf-4136c566a962Use str(uuid.uuid4()) when you need a plain string. (Link: Python UUID v4 guide.)
Go
Go’s standard library has no UUID package, so most projects use the widely adopted github.com/google/uuid module.
import “github.com/google/uuid”
package main
import (
"fmt"
"github.com/google/uuid"
)
func main() {
id := uuid.New()
fmt.Println(id.String())
}uuid.New() panics if the system’s random source fails. Use uuid.NewRandom() if you prefer to handle that error yourself. (Link: Go UUID v4 guide.)
PHP
PHP has no built-in UUID function, so you can build one from random_bytes() by setting the version and variant bits yourself.
<?php
$data = random_bytes(16);
$data[6] = chr((ord($data[6]) & 0x0f) | 0x40); // version 4
$data[8] = chr((ord($data[8]) & 0x3f) | 0x80); // variant 10xx
echo vsprintf('%s%s-%s-%s-%s-%s%s%s', str_split(bin2hex($data), 4));Many projects use the ramsey/uuid library instead, which wraps the same logic. (Link: PHP UUID v4 guide.)