UUID Generator
Generate version 4 UUIDs in single or bulk mode.
About the UUID Generator
A UUID (Universally Unique Identifier, RFC 4122) is a 128-bit identifier typically displayed as 32 hexadecimal digits separated by hyphens into five groups: 8-4-4-4-12. The most widely used variant is UUIDv4, which reserves 4 bits for the version and 2-3 bits for the variant, leaving 122 bits of pure randomness — enough that the probability of collision between two independent v4 UUIDs is astronomically small until you have generated roughly 2.71 × 10^17 of them (the birthday-paradox threshold).
UUIDs are the default identifier in distributed systems precisely because they remove the need for a central coordinator. Databases, microservices, message queues, and object-storage systems (S3, GCS) all assign UUIDs as primary keys, message IDs, and object keys. AWS, Azure, and Google Cloud use UUIDs internally for trace IDs, request IDs, and resource identifiers because they can be generated independently on different machines without ever colliding.
This generator runs entirely in your browser via crypto.getRandomValues, so UUIDs you generate here are suitable for use as database primary keys, JWT IDs (jti claim), OAuth client secrets, distributed-trace span IDs, and test fixtures. The output is never sent over the network.
How It Works
A version-4 UUID begins by requesting 16 bytes (128 bits) of cryptographically secure randomness from crypto.getRandomValues. Two of those bytes are then overwritten to encode the version and variant bits required by RFC 4122:
- Byte 6 (octet 6): the high nibble is set to
0100(binary), which is the hex digit4. This marks the UUID as version 4. The low nibble keeps its random value. - Byte 8 (octet 8): the top two bits are set to
10(binary), which forces the high nibble to one of8,9,A, orB. This marks the UUID as the RFC 4122 / Leach-Salz variant.
After these two byte-level surgeries, 122 bits of true randomness remain. Each byte is converted to a two-digit hex string and concatenated in the standard 8-4-4-4-12 layout: xxxxxxxx-xxxx-4xxx-[89AB]xxx-xxxxxxxxxxxx. The output uses lowercase hex by convention but is case-insensitive for parsing purposes.
The nil UUID is a special case defined in RFC 4122 — all 128 bits set to zero (00000000-0000-0000-0000-000000000000). It is used as a sentinel value meaning “no identifier” in protocols like BLE (Bluetooth Low Energy), where it represents “no service” in the service UUID field.
Collision math: the probability that any two of n independently generated v4 UUIDs collide is approximately n^2 / (2 × 2^122). Generating 103 trillion UUIDs gives a collision probability of about one in a billion — well beyond any practical system’s lifetime.
Worked Examples
Generating a single v4 UUID typically produces something like 3f2504e0-7e7c-4d8a-9b3a-2c91b8a1a1a1. The third group always starts with 4, marking version 4. The fourth group always starts with 8, 9, A, or B, marking the RFC 4122 variant. The remaining 122 bits are random.
Generating 10 UUIDs in one call gives 10 unique values — not just probably unique, but with overwhelming statistical certainty. Even if you generated 100 UUIDs every second for 50 years, you would not approach the birthday-bound collision threshold.
In uppercase mode, the same UUID becomes 3F2504E0-7E7C-4D8A-9B3A-2C91B8A1A1A1. The Microsoft GUID convention wraps this in braces: {3F2504E0-7E7C-4D8A-9B3A-2C91B8A1A1A1}. Microsoft tools (Visual Studio, .NET, SQL Server) often use this brace-wrapped form, while most open-source tooling uses the bare hyphenated form.
The nil UUID 00000000-0000-0000-0000-000000000000 is reserved and should never be used as a random identifier — it is a sentinel. If you generate one for production use, your code is buggy.
When to Use This Tool
- Primary keys in distributed databases where an auto-increment integer would create contention or require coordination.
- JWT
jti(JWT ID) claim to prevent token replay attacks. - Distributed-tracing span IDs in OpenTelemetry, Jaeger, and Zipkin.
- S3 object keys when you need a globally unique filename without server-side coordination.
- Message IDs in event-driven systems (Kafka, RabbitMQ, NATS) for idempotent consumers.
- Test fixtures and seed data in unit tests where deterministic identifiers would cause false negatives.
- Bluetooth Low Energy service and characteristic UUIDs for custom hardware profiles.
Limitations & Disclaimer
UUIDv4 values generated here are random and should not be used as the sole authentication credential, access token, or password — they are designed for uniqueness, not unpredictability against targeted guessing. The 122 bits of entropy is sufficient for collision avoidance but a determined attacker scanning 2^32 (4.3 billion) candidate UUIDs per second against a known victim’s identifier could exhaustively probe the namespace in centuries, not millennia. For session tokens, use a separate 256-bit CSPRNG token. UUIDv1 (MAC-based) and v6/v7 (time-ordered) variants are not generated here; for time-sorted identifiers that reduce index fragmentation, use UUIDv7 from a dedicated library. See our disclaimer for full terms.
Frequently Asked Questions
Are UUIDv4 values truly unique?
With 122 bits of randomness, the chance that two UUIDv4 values collide is roughly <code>1 in 2.71 × 10^17</code> after generating 2.71 × 10^17 IDs (the birthday bound). For practical systems generating millions of UUIDs per day, collision is effectively impossible. The risk is far smaller than disk corruption, CPU error, or cosmic-ray bit flips.
What is the difference between UUID and GUID?
Functionally, none. GUID is Microsoft’s name for UUID and follows the same RFC 4122 standard. The only visible difference is that Microsoft tooling typically wraps GUIDs in braces (<code>{...}</code>) and renders them in uppercase. The 128-bit value is identical and they interoperate transparently.
Can I use these as database primary keys?
Yes. UUIDs are the standard choice for distributed databases (Cassandra, DynamoDB, MongoDB, Spanner) and for sharded SQL databases. They remove the need for an auto-increment coordinator. The trade-off is storage: 16 bytes binary or 36 bytes text versus 4-8 bytes for a bigint. Index fragmentation can also be worse with random v4 UUIDs; consider UUIDv7 (time-ordered) for time-series workloads.
Why is the third group always ‘4’?
That hex digit encodes the UUID version. RFC 4122 specifies that bits 48-51 of a v4 UUID must be <code>0100</code> (binary), which is <code>4</code> in hex. If you see a UUID whose third group starts with anything other than <code>4</code>, it is either a v1 (time-based), v3 (MD5-named), v5 (SHA-1-named), v6 (reordered time), or v7 (time-ordered random) UUID — not a v4.
Is the output secure enough for session tokens?
For non-secret identifiers, yes. For session tokens, session IDs, or password-reset tokens, a UUID alone is not enough because UUIDs are designed to be unique, not unpredictable. Use a CSPRNG-derived 32-byte token (256 bits) for session authentication. UUIDs are fine as public-facing IDs but should never be the sole authentication credential.
What is the nil UUID for?
The nil UUID (<code>00000000-0000-0000-0000-000000000000</code>) is a reserved sentinel meaning “no UUID” or “unspecified.” It is used in Bluetooth Low Energy to mean “no service,” in GPT partition tables for “no partition type,” and in some RPC protocols to indicate “no object.” Never generate a nil UUID for production use.
Last updated: July 21, 2026 · Author: HT99 Tools Editorial Team · Reviewed by: HT99 Tools Editorial Team