How to Generate a UUID

When you need a unique identifier that will never collide with another — across servers, databases, or even organizations — a UUID is the standard answer. The UUID Generator lets you create one or a batch instantly, without installing anything or writing code.

Understanding UUID versions

Not all UUIDs are the same. The two most commonly used versions today are v4 and v7, and choosing between them has real consequences for your application.

UUID v4 is completely random. Every bit (except the version and variant markers) is generated from a cryptographically secure random source. This makes v4 UUIDs unpredictable and evenly distributed, which is great for security-sensitive identifiers like session tokens or API keys. The probability of a collision is astronomically low — you would need to generate about 2.71 quintillion UUIDs to have a 50% chance of a single duplicate.

UUID v7 embeds a Unix timestamp in the first 48 bits, with the remaining bits filled randomly. This means v7 UUIDs are time-sortable — when you sort them lexicographically, they come out in chronological order. This property is extremely valuable for database primary keys because it preserves insert order and plays well with B-tree indexes.

Tips and best practices

• Use UUID v7 for database primary keys. Random v4 UUIDs cause index fragmentation in B-tree-based databases (PostgreSQL, MySQL) because each insert lands at a random position in the index. V7 UUIDs insert sequentially, keeping your indexes compact and your writes fast.
• Use UUID v4 when unpredictability matters. For tokens, nonces, or any identifier that should not reveal when it was created, v4 is the right choice.
• Store UUIDs as native UUID types in your database when available, not as VARCHAR(36). Native UUID columns use 16 bytes instead of 36 and support efficient indexing.
• Lowercase your UUIDs. The RFC treats UUIDs as case-insensitive, but storing and comparing them in consistent lowercase avoids subtle bugs.
• Do not use UUIDs as short identifiers for users. A 36-character string is unwieldy in URLs and impossible to read over the phone. Consider a shorter ID scheme for user-facing identifiers and keep UUIDs for internal use.

Common issues

• Performance degradation with v4 primary keys: If your table has millions of rows and you are using random UUIDs as the primary key, you may notice slower inserts over time. Switching to UUID v7 or using a ULID typically resolves this.
• String comparison failures: UUIDs generated in different cases (A3F... vs a3f...) will fail string equality checks even though they represent the same UUID. Normalize to lowercase before comparing.
• Accidental duplicates in tests: Hardcoding UUID strings in test fixtures and accidentally reusing them across tests causes flaky failures. Generate fresh UUIDs in each test setup instead.