# How to Generate a UUID

> Generate random UUIDs (v4) or time-based UUIDs (v7) for use as unique identifiers in databases, APIs, and applications.

- URL: https://www.browserutils.dev/how-to/generate-uuid
- Published: 2026-03-05
- Updated: 2026-03-16

---

## Step 1: Choose UUID version

Select UUID v4 (random) for general-purpose unique IDs, or UUID v7 (time-based) for sortable IDs.

## Step 2: Generate one or many

Click generate for a single UUID, or set a count to generate multiple UUIDs at once.

## Step 3: Copy the result

Click to copy individual UUIDs or the entire batch. UUIDs are formatted in the standard 8-4-4-4-12 hex format.

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](/tools/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.