RH
Tool

UUID Generator

Generate unique UUID v1 and v4 identifiers

Client-side processing
e67c46cd-c2bc-481a-93b8-acb5f39f09a6
e51be23f-88ff-4de3-931c-87fffd51f44d
c2b30f4c-2ca0-4334-985d-18382b786a84
3ba97d88-d2c3-4f4d-b274-b57b389cfb1c
1ed27a26-7d9e-4570-8ad7-a66d448318d9
Info

Online UUID Generator - Version 4, Version 1 and ULID

What is a UUID and what is it used for in programming?

A UUID (Universally Unique Identifier) is a standard 128-bit identifier, written as 32 hexadecimal digits in the 8-4-4-4-12 layout, designed to be globally unique without any central coordination or registry. UUIDs are used extensively as primary keys in distributed databases and microservices, user session identifiers, financial transaction tokens, unique file names in cloud storage, resource IDs in REST APIs, IoT device identifiers, and anywhere you need identifiers that will not collide across independent systems, servers or databases.

What are the UUID versions and how do they differ?

Several UUID versions exist with distinct characteristics. UUID v1 combines a 60-bit timestamp, the machine MAC address and a counter, which guarantees temporal uniqueness but leaks information about when and where it was generated. UUID v4 is fully random with 122 bits of entropy, and it is the most widely used version thanks to its simplicity and privacy. UUID v5 produces deterministic identifiers derived from a namespace and a name using SHA-1, useful when the same input must always yield the same UUID. UUID v7 (RFC 9562, 2024) is the new recommendation: it combines a sortable millisecond Unix timestamp with randomness, which is ideal for databases where insertion order affects index performance.

How do UUIDs affect database performance?

Using random UUIDs (v4) as a primary key has real performance implications: B-tree indexes suffer from random insertions, causing page splits and fragmentation, and the 36-character text form (or 16 bytes binary) consumes more space than an auto-increment integer. To mitigate that, UUID v7 or ULID (Universally Unique Lexicographically Sortable Identifier) give you natural time ordering. PostgreSQL has an optimized native UUID type. In MySQL, store UUIDs as BINARY(16) instead of CHAR(36), or use UUID_TO_BIN() with swap_flag for better ordering. It is also worth asking whether you truly need UUIDs or whether sequential IDs cover your use case.

If you work with this tool, you will probably also find these useful JWT Secret Generator, Hash Generator, Password Generator, Lorem Ipsum Generator.

Frequently asked questions

Can two randomly generated UUIDs (v4) collide?

A collision is theoretically possible but astronomically unlikely. With the 122 bits of randomness in UUID v4 you would need to generate roughly 2.71 x 10^18 UUIDs to reach even a 50% chance of a single collision (the birthday paradox). In practice that means collisions are effectively impossible for any real application. Generating a million UUIDs per second, you would need 85 years to reach a 0.000001% chance of a collision.

What is the difference between UUID and GUID?

They are essentially the same thing under different names. GUID (Globally Unique Identifier) is the term Microsoft uses in Windows and .NET technologies, while UUID is the term from the RFC 4122 international standard used across the rest of the industry. The 128-bit structure, the 8-4-4-4-12 representation and the purpose are identical. You can use the terms interchangeably, though UUID is technically the official standard name.

Can I use a UUID as a security token or API key?

UUID v4 carries 122 bits of cryptographic entropy, which is adequate for medium-security tokens such as one-time password reset links or email verification tokens. For long-lived API keys, critical authentication tokens or session keys, prefer a dedicated cryptographic generator that produces longer tokens of 256 bits or more. Also consider signed JWTs when the token must carry verifiable claims, or opaque tokens stored hashed in your database.

© 2026
Roberto Hernando
|