UUID Generator

Generate UUIDs in v4 (random) or v7 (time-ordered) format.

Free Online UUID Generator

UUIDs are essential for database primary keys, request tracing, and distributed systems. Dokall generates RFC-compliant UUID v4 (random) and UUID v7 (time-sortable) values you can copy with one click.

Generate single UUIDs or batches for testing. All generation happens locally in your browser - fast, private, and no rate limits.

What is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit value formatted as 32 hexadecimal digits in five groups separated by hyphens: 550e8400-e29b-41d4-a716-446655440000. UUIDs are designed to be unique across space and time without requiring a central authority to assign them.

UUIDs are used as database primary keys, API request identifiers, distributed system correlation IDs, file names, and session tokens. Their key advantage is that any system can generate a UUID independently, and the probability of collision is negligible - you would need to generate about 2.71 quintillion UUIDs to have a 50% chance of a single collision.

UUID Versions Explained

There are several UUID versions, each using a different generation strategy.

UUID v1 combines the current timestamp with the machine's MAC address. It is unique and roughly time-ordered, but it leaks the MAC address and exact creation time - a privacy concern in some contexts.

UUID v4 is generated from cryptographically random numbers. 122 of the 128 bits are random (6 bits encode the version and variant). This is the most commonly used version because it is simple, private, and has excellent collision resistance.

UUID v5 (and v3) generates a deterministic UUID from a namespace and a name using SHA-1 (v5) or MD5 (v3) hashing. Given the same namespace and name, you always get the same UUID. Useful for generating consistent IDs from natural keys.

UUID v7 (RFC 9562, 2024) encodes a Unix timestamp in the first 48 bits, followed by random data. This makes v7 UUIDs naturally time-ordered while still being unique. This is a significant advantage for database indexing.

UUID v4 vs UUID v7

UUID v4 is purely random - there is no inherent order. When used as a database primary key with a B-tree index, random UUIDs cause writes to scatter across the index, leading to poor cache utilization and increased I/O. This is called index fragmentation.

UUID v7 embeds a timestamp in the first 48 bits, making the IDs monotonically increasing over time. New records are appended to the end of the B-tree index instead of scattered randomly. This dramatically improves write performance and index locality - in benchmarks, v7 can be 2-5x faster than v4 for insert-heavy workloads.

UUID v7 also lets you extract an approximate creation timestamp from the ID itself, which can be useful for debugging, sorting, and data lifecycle management. The trade-off: v7 reveals when the record was created, which may be a concern if creation time is sensitive.

For new projects, UUID v7 is the recommended choice unless you specifically need the non-sequential property of v4 (for example, to prevent enumeration attacks on public-facing IDs).

UUID as a Database Primary Key

UUIDs as primary keys have clear benefits: they can be generated client-side without a database round-trip, they are unique across tables and databases, and they do not reveal record count or creation order (v4). This makes them ideal for distributed systems, offline-first apps, and APIs where exposing sequential IDs is undesirable.

The downsides: UUIDs are 16 bytes vs 4-8 bytes for integer IDs. This increases storage, memory usage, and join costs. String representation (36 characters) is even larger in text-based storage. Random UUIDs (v4) cause B-tree index fragmentation as mentioned above.

Practical recommendations: use UUID v7 to avoid index fragmentation. Store UUIDs as binary(16) or a native UUID type (PostgreSQL has a uuid type), not as varchar(36). If your database supports it, use the UUID type for better storage and comparison performance.

UUID vs Auto-Increment vs ULID vs Nano ID

Auto-increment IDs (SERIAL, IDENTITY) are sequential integers assigned by the database. They are compact (4-8 bytes), fast to index, and easy to read. Downsides: they require a database round-trip to generate, they expose record count and creation order, and they are not unique across tables or databases.

UUIDs are globally unique and can be generated anywhere. Downsides: larger storage (16 bytes), and v4 causes index fragmentation (solved by v7).

ULID (Universally Unique Lexicographically Sortable Identifier) is a 128-bit ID with a 48-bit timestamp prefix, similar to UUID v7 but with a more compact string representation (26 Crockford Base32 characters vs 36 hex characters). ULIDs sort lexicographically by time.

Nano ID generates random string IDs with a configurable alphabet and length. A 21-character Nano ID has roughly the same collision resistance as UUID v4 but is shorter. Useful for URL-friendly IDs where the full 128-bit UUID format is unnecessary.

Choose auto-increment for simple single-database applications. Choose UUID v7 for distributed systems or APIs. Choose ULID or Nano ID when string length matters.

Frequently Asked Questions

Can two UUIDs ever be the same?
Theoretically, yes. For UUID v4, the probability of generating two identical UUIDs is astronomically low - you would need to generate about 2.71 x 10^18 (2.71 quintillion) UUIDs to have a 50% chance of a collision. In practice, this is treated as impossible. More UUIDs are generated every day across all systems worldwide than you will generate in your lifetime, and collisions have never been observed.
What is the difference between UUID v4 and UUID v7?
UUID v4 is purely random (122 random bits). UUID v7 embeds a Unix millisecond timestamp in the first 48 bits, followed by random data. This makes v7 UUIDs time-ordered, which greatly improves database insert performance with B-tree indexes. Use v7 for database keys; use v4 when you need non-sequential, non-time-revealing IDs.
Should I use UUIDs or auto-increment IDs in my database?
Use auto-increment for simple, single-database apps where sequential IDs are not a security concern. Use UUIDs (preferably v7) when you need globally unique IDs, client-side ID generation, cross-database uniqueness, or when exposing sequential IDs in APIs is undesirable. The storage overhead of UUIDs (16 bytes vs 4-8 bytes) is rarely a practical concern for modern databases.
How long is a UUID?
A UUID is 128 bits (16 bytes) of binary data. In the standard string representation, it is 36 characters: 32 hexadecimal digits plus 4 hyphens, formatted as 8-4-4-4-12 (e.g., 550e8400-e29b-41d4-a716-446655440000). When stored in a database, use a binary(16) or native UUID column type rather than varchar(36) for better performance.
Are UUIDs sequential?
UUID v4 is not sequential - it is purely random. UUID v1 and v7 are roughly sequential because they incorporate timestamps. UUID v7 is specifically designed to be monotonically increasing, making it ideal for database indexing. If you need non-sequential IDs (to prevent enumeration), use v4.
What is a ULID and how does it compare to UUID?
ULID (Universally Unique Lexicographically Sortable Identifier) is a 128-bit ID with a 48-bit timestamp prefix and 80 bits of randomness. It is similar to UUID v7 but uses a more compact Crockford Base32 encoding (26 characters vs UUID's 36). ULIDs sort as strings by creation time. Choose ULID when you want time-sorted IDs with shorter string representation.
Can I extract a timestamp from a UUID?
From UUID v1 and v7, yes. UUID v7 stores a Unix millisecond timestamp in the first 48 bits, which can be extracted to determine when the UUID was generated (to millisecond precision). UUID v4 contains no timestamp - it is purely random. UUID v1 contains a timestamp but uses a different epoch (October 15, 1582) and a 100-nanosecond resolution.

Related Tools

Random KeygenAPI keys, JWT secrets, hex keys, UUIDs, and more - click to copy.Hash Text (Crypto)Hash text with SHA, HMAC, hex or Base64 output, and hash comparison.Password GeneratorGenerate strong random passwords instantly.