UUID stands for Universally Unique Identifier. It is a 128-bit label used to uniquely identify information in computer systems without requiring a central authority to assign IDs. UUIDs are standardised in RFC 4122 (and RFC 9562 for newer versions) and formatted as 32 hexadecimal digits in five groups: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. A typical UUID looks like f47ac10b-58cc-4372-a567-0e02b2c3d479.

UUID Versions

There are five UUID versions defined in RFC 4122, plus newer versions added in 2022. The ones you will encounter most often are v1, v4, and increasingly v7.

UUID v4 — Random

UUID v4 is generated from random or pseudo-random numbers. It contains no information about when or where it was created. The 13th character is always 4 (the version indicator) and the 17th character is always 8, 9, a, or b (the variant indicator). Everything else is random. This is the most commonly used version for general-purpose unique identifiers — use v4 unless you have a specific reason not to.

UUID v1 — Timestamp + MAC Address

UUID v1 encodes the current timestamp (in 100-nanosecond intervals since October 15, 1582) and the MAC address of the generating machine. This means two v1 UUIDs generated on the same machine will have related values, and the time of creation can be extracted from the UUID. This is useful for time-ordered identifiers but a privacy concern if the MAC address should not be exposed. Modern implementations often use a random node ID instead of the actual MAC address.

UUID v7 — Unix Timestamp + Random (Recommended for Databases)

UUID v7 is a newer version (RFC 9562, 2022) that encodes milliseconds since the Unix epoch in the most significant bits, followed by random bits. The key advantage over v4 is that v7 UUIDs sort chronologically — they are monotonically increasing, which means database indexes remain sorted and insert performance does not degrade over time. If you are using UUIDs as database primary keys and your database supports UUID v7, use it over v4.

Generate UUIDs instantly UUID v4, sortable UUID v7, or legacy v1 — single or bulk up to 100, with no-hyphens and URN formats.
Open UUID Generator →

UUID vs GUID

GUID (Globally Unique Identifier) is Microsoft's term for UUID. They follow the same RFC 4122 standard and produce identical output. The choice of which term to use is determined by the platform: GUIDs in .NET and SQL Server, UUIDs in most other contexts. They are completely interchangeable.

UUIDs as Database Primary Keys

Using UUIDs as primary keys is a common architectural choice with genuine trade-offs on both sides. The advantages: UUIDs can be generated client-side without a database round-trip, they are safe to expose in URLs without revealing record counts, they are safe to merge across databases without ID collisions, and they work naturally in distributed systems.

The disadvantages: 16 bytes storage versus 4–8 for integers, random v4 UUIDs cause index fragmentation because inserts are not sequential (each new row goes to a random position in the B-tree index), and they are harder to debug because humans cannot easily compare or remember them.

The index fragmentation problem is why UUID v7 matters for database use — because v7 is time-ordered, inserts are always at the end of the index, just like auto-incrementing integers. PostgreSQL 17 adds native UUID v7 generation with uuidv7().

Generating UUIDs in Code

// JavaScript — Node.js 16+ and modern browsers crypto.randomUUID() // v4 # Python import uuid str(uuid.uuid4()) # v4 str(uuid.uuid1()) # v1 // Java import java.util.UUID; UUID.randomUUID().toString() // v4 // Go import "github.com/google/uuid" uuid.New().String() // v4 -- PostgreSQL SELECT gen_random_uuid(); -- v4 (built-in) SELECT uuidv7(); -- v7 (PostgreSQL 17+) -- MySQL 8+ SELECT UUID(); -- v1

Frequently Asked Questions

How unique is a UUID really?
UUID v4 has 122 random bits (6 bits are fixed for version and variant). The probability of generating a duplicate UUID is approximately 1 in 5.3 × 10³⁶. To have a 50% chance of a collision, you would need to generate approximately 2.7 quintillion UUIDs. For any real-world application, collisions are not a practical concern — they are theoretically possible but not something to engineer against.
Should I use UUID or auto-increment integer as a primary key?
It depends on your use case. Auto-increment integers are smaller (4–8 bytes), faster to index, and simpler to debug. UUIDs are better when you need to generate IDs without a database, merge data from multiple databases, or avoid exposing sequential record counts in URLs. For most applications, either works fine. For high-throughput insert workloads with UUID primary keys, use UUID v7 to avoid index fragmentation.
What is the difference between UUID v4 and UUID v7?
UUID v4 is entirely random — it contains no time information and inserts into a UUID-indexed table in random order, causing index fragmentation. UUID v7 encodes the current Unix timestamp in milliseconds in the leading bits, so v7 UUIDs sort chronologically and insert in order, like auto-incrementing integers. Use v4 for general-purpose identifiers. Use v7 for database primary keys where insert performance matters.
Is UUID the same as GUID?
Yes — GUID is Microsoft's term for UUID. Both follow RFC 4122 and produce identical output. The terms are fully interchangeable. GUIDs are used in .NET and SQL Server contexts; UUIDs are the standard term everywhere else.