What Is a UUID?
A UUID (Universally Unique Identifier) is a 128-bit value used to label a record, resource, or other item in a computer system. Since UUIDs can be generated independently, they are useful when separate services need identifiers without asking one central counter for each new value.
UUIDs are standardized under RFC 9562 (which supersedes the original RFC 4122). You'll encounter them everywhere in software: database primary keys, session tokens, file names, API resource identifiers, distributed tracing IDs, and more.
The UUID Format Explained
A UUID is always displayed in the same canonical text format, regardless of version:
550e8400-e29b-41d4-a716-446655440000
That string of 32 hexadecimal characters, split into five groups separated by hyphens, follows the pattern 8-4-4-4-12:
- 8 hex digits - first group (32 bits)
- 4 hex digits - second group (16 bits)
- 4 hex digits - third group, where the first digit encodes the version (16 bits)
- 4 hex digits - fourth group, where the first 1-3 bits encode the variant (16 bits)
- 12 hex digits - fifth group (48 bits)
The third group's leading digit tells you the UUID version at a glance. A UUID starting with ...41d4... in the third group is version 4 (random). One starting with ...11d4... is version 1 (time-based).
In total, 128 bits = 16 bytes = 32 hex characters. The hyphens are cosmetic - most databases store UUIDs as a compact 16-byte binary value internally.
All Five UUID Versions Compared
The RFC defines five original versions, each using a different strategy to achieve uniqueness. A sixth version (v7) is newer and increasingly popular.
| Version |
Algorithm |
Uniqueness Source |
Sortable? |
Best Use Case |
| v1 |
Time-based |
Timestamp + MAC address of the generating machine |
Yes (time-ordered) |
Distributed logs where chronological ordering matters |
| v3 |
Name-based (MD5) |
MD5 hash of a namespace + name string |
No |
Deterministic IDs for the same resource (e.g., URL → UUID) |
| v4 |
Random |
122 bits of cryptographically random data |
No |
General-purpose IDs: database keys, session tokens, API resources |
| v5 |
Name-based (SHA-1) |
SHA-1 hash of a namespace + name string |
No |
Deterministic IDs, same as v3 but with a stronger hash |
| v7 |
Time-ordered random |
Unix timestamp (ms precision) + random bits |
Yes (lexicographically) |
Database primary keys requiring both uniqueness and insert order |
UUID v1 - Time-Based
Version 1 builds uniqueness from the current timestamp (a 60-bit value measured in 100-nanosecond intervals since October 15, 1582) combined with the generating machine's MAC address. The time component ensures different moments produce different UUIDs; the MAC address differentiates machines generating UUIDs at the same instant.
The downside is privacy: the MAC address is embedded in every v1 UUID you generate, leaking information about the originating hardware. This is why v1 is rarely recommended for internet-facing systems today. It also front-loads the time component in the middle of the string (the 8-4 section stores the lower time bits first), making v1 UUIDs non-sortable in their natural string form.
UUID v3 and v5 - Name-Based
These versions are deterministic: given the same namespace and name, they always produce the same UUID. Version 3 uses MD5 hashing; version 5 uses SHA-1. You would use these when you need a consistent, repeatable identifier for a specific resource - for example, turning a canonical URL into a UUID that's always the same UUID for that URL.
Because MD5 is considered cryptographically broken for security purposes, v5 (SHA-1) is preferred over v3. Neither should be used when security or unpredictability is required.
UUID v4 - Random (The Most Common)
Version 4 is the default choice for most applications. It fills 122 bits with cryptographically secure random data (6 bits are consumed by the version and variant fields). There's no timestamp, no MAC address, no predictability. Each v4 UUID is an independent roll of a 122-bit die.
The vast majority of UUID generators you'll encounter online - including the Kinsad UUID Generator - produce v4 UUIDs by default. When someone says "generate a UUID," they almost always mean v4.
UUID v7 - The Modern Choice for Databases
UUID v7 is a newer addition that addresses the biggest practical weakness of v4 for databases: index fragmentation. Because v4 UUIDs are random, inserting them into a B-tree index (like a SQL primary key) scatters new rows across the tree rather than appending to the end. This causes expensive page splits and poor cache utilization at scale.
Version 7 places a Unix timestamp in the most significant bits, so its textual form sorts roughly by creation time. That ordering can improve insertion locality compared with random v4 values, but it also reveals approximate creation time and does not make every database workload equivalent to sequential integers. Check your database and library support, and consider whether exposing timestamps matters for your application.
💡 Tip: Not sure which version to generate? Use the
Kinsad UUID Generator to create UUIDs in any version - v1 through v7 - instantly and for free.
How Likely Is a UUID Collision?
The "universally unique" claim sounds bold, but the math backs it up. For UUID v4 with 122 random bits, the probability of generating at least one duplicate across N UUIDs follows the birthday problem formula:
To have a 50% chance of at least one collision, you'd need to generate approximately 2.71 × 10¹⁸ UUIDs - that's 2.71 quintillion unique identifiers. To put that in perspective:
- If every person on Earth (8 billion people) generated one UUID every second, it would take approximately 10 billion years to reach 50% collision probability.
- If every computer on Earth generated a million UUIDs per second, the expected time to first collision is still measured in millions of years.
- The total number of atoms in a grain of sand is roughly 10¹⁹ - comparable to the collision threshold.
In practice, UUID collisions are not a realistic engineering concern. The far more likely failure mode is a bug in your random number generator - which is why UUID libraries always use cryptographically secure pseudorandom number generators (CSPRNGs) rather than ordinary Math.random()-style functions.
⚠️ Warning: Never generate UUIDs using a non-cryptographic random number generator like JavaScript's Math.random(). The low-quality randomness dramatically increases collision probability and, more importantly, makes IDs predictable - a security risk if UUIDs are used for access control. Use crypto.randomUUID() in modern browsers and Node.js, or a vetted UUID library.
UUID vs Auto-Increment: Which Should You Use?
Auto-incrementing integers (1, 2, 3, 4…) have been the default for database primary keys since relational databases were invented. UUIDs challenge that default. Here's how they compare across the dimensions that matter:
| Consideration |
Auto-Increment Integer |
UUID (v4 or v7) |
| Privacy |
❌ Exposes record count and creation order (e.g., /users/1042 tells attackers you have ~1000 users) |
✅ No information leakage - IDs are opaque |
| Distributed generation |
❌ Requires a central database sequence; can't generate offline or across multiple databases |
✅ Any service or client can generate a valid ID independently |
| Merge & replicate |
❌ Conflicts when merging data from multiple sources or shards |
✅ No conflicts - IDs are globally unique regardless of origin |
| Storage size |
✅ 4 bytes (INT) or 8 bytes (BIGINT) |
❌ 16 bytes (binary) or 36 bytes (text with hyphens) |
| Index performance |
✅ Sequential inserts are fast; index stays compact |
⚠️ v4 causes index fragmentation; v7 matches integer performance |
| Readability |
✅ Short and easy to remember for debugging |
❌ Long and hard to remember or type manually |
| Predictability (security) |
❌ Sequential IDs are easy to enumerate (IDOR attacks) |
✅ Random IDs cannot be guessed or enumerated |
| Client-side generation |
❌ Must wait for database to return the generated ID |
✅ Client generates the ID before the insert, enabling optimistic UI |
The right answer depends on the database, access patterns, and operational needs. A single-database application may find integer keys simpler and more compact; independently created records or data that must merge across systems may benefit from UUIDs. A UUID's hard-to-guess appearance is not, by itself, an authorization check or proof that a resource should be accessible.
Implementing UUIDs in SQL Databases
Most modern databases have native UUID support, but the details vary:
PostgreSQL
PostgreSQL has a built-in uuid data type that stores UUIDs as 16-byte binary values while displaying them in the canonical hyphenated format. Use it as a primary key with gen_random_uuid() (available since PostgreSQL 13) as the default:
CREATE TABLE users (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
email TEXT NOT NULL,
created_at TIMESTAMPTZ DEFAULT NOW()
);
This generates a v4 UUID for every new row automatically. For v7 UUIDs in PostgreSQL, use the pg_uuidv7 extension.
MySQL / MariaDB
MySQL's UUID() function generates v1 UUIDs. For better index performance, store UUIDs as BINARY(16) using UUID_TO_BIN(UUID(), 1), where the 1 flag swaps the time components to make insertion order match time order:
id BINARY(16) DEFAULT (UUID_TO_BIN(UUID(), 1))
SQLite
SQLite has no native UUID type. Store them as TEXT (36 characters) or BLOB (16 bytes). Generate them in your application layer before insertion.
💡 Tip: Always store UUIDs in their binary form (16 bytes) rather than as a string (36 characters) in your database. This cuts storage size by more than half and significantly speeds up index lookups and JOIN operations on UUID columns.
ULID: A Modern Alternative Worth Knowing
The ULID (Universally Unique Lexicographically Sortable Identifier) is a newer alternative that combines the best of UUIDs and auto-increment integers. A ULID looks like 01ARZ3NDEKTSV4RRFFQ69G5FAV.
Key differences from UUID:
- Lexicographically sortable: The first 48 bits encode a millisecond timestamp, so ULIDs sort in creation order - just like UUID v7.
- URL-safe: Uses Crockford Base32 encoding (uppercase letters and digits only, no hyphens), making it safe for URLs without any encoding.
- Slightly shorter: 26 characters vs UUID's 36 characters.
- Less universal: Unlike UUIDs, ULIDs aren't an IETF standard, and database-native support is limited.
For most new projects, UUID v7 and ULID are both excellent choices over UUID v4 when database performance matters. UUID v7 has the advantage of being an official RFC standard with growing native database support.
Generating UUIDs: Language Quick Reference
Here's how to generate a v4 UUID in the most common programming languages:
- JavaScript / Node.js:
crypto.randomUUID() (built-in, no library needed)
- Python:
import uuid; str(uuid.uuid4())
- Java:
UUID.randomUUID().toString()
- C# / .NET:
Guid.NewGuid().ToString()
- Go: Use the
github.com/google/uuid package: uuid.New().String()
- Ruby:
require 'securerandom'; SecureRandom.uuid
- PHP:
Str::uuid() (Laravel) or the ramsey/uuid library
- Rust: Use the
uuid crate: Uuid::new_v4().to_string()
Frequently Asked Questions
Q: What is the difference between UUID and GUID?
Functionally, nothing - they're the same thing. GUID (Globally Unique Identifier) is Microsoft's term for UUID, used in Windows and .NET. Both follow the same RFC 4122 / RFC 9562 standard and have the same 8-4-4-4-12 format. You can use GUIDs and UUIDs interchangeably.
Q: Can I use a UUID as a URL?
Yes, UUIDs are safe in URL paths and query parameters. Hexadecimal characters (0-9 and a-f) and hyphens don't require URL encoding. A URL like /api/orders/550e8400-e29b-41d4-a716-446655440000 is perfectly valid. If you want shorter URLs, consider using Base58 encoding of the UUID's 16 bytes.
Q: Should I use uppercase or lowercase UUIDs?
The RFC specifies lowercase for UUID strings, and most modern libraries output lowercase. Comparisons should always be case-insensitive since both forms represent the same value. For consistency, stick with lowercase throughout your codebase and normalize incoming values to lowercase before comparing or storing.
Q: Is UUID v4 safe to use as a secret token?
With caveats. A UUID v4 has 122 bits of entropy, which is enough to be unguessable. However, dedicated secret tokens (like session IDs or API keys) should use 256 bits of entropy or more. UUID v4 is acceptable for short-lived tokens or non-critical access control, but for anything security-critical, generate a full 256-bit random token using your platform's CSPRNG.
Q: Why do some UUIDs look similar at the start?
If you generate UUID v1, the timestamp occupies the first 32 bits (though stored in a non-obvious byte order). UUIDs generated in rapid succession may share a common prefix because the timestamp portion hasn't changed. UUID v4 avoids this - every position is independent random data, so there's no visible pattern in the output.
Try It Free on Kinsad
Generate UUID v1, v3, v4, v5, or v7 instantly with our free online tool. Copy single UUIDs or generate bulk batches - no sign-up required and nothing is stored on our servers.
Use the UUID Generator →