UUIDs are the default identifier format for databases, APIs, and distributed systems. Whether you’re seeding a test database, generating API keys, or creating primary keys for a new schema, you need a way to generate them quickly. A UUID generator is one of those tools every developer reaches for occasionally.
The question in 2026 is no longer “which UUID version” — it’s “v4 or v7?”
UUID v4 vs v7: which to use
UUID v4 is pure random. 122 random bits, 6 bits for version and variant. No pattern, no time correlation, no way to guess the next ID.
Use v4 for:
- Session tokens
- Password reset links
- API keys distributed to third parties
- Anything where the ID itself is the security boundary
UUID v7 is time-ordered. The first 48 bits are a millisecond-precision Unix timestamp, followed by random bits. UUIDs generated in the same millisecond sort in insertion order.
Use v7 for:
- Database primary keys (4x faster inserts than v4 in MySQL)
- Event log IDs
- Message queue message IDs
- Distributed system identifiers where you want coarse ordering
The PlanetScale benchmark (2024) showed UUID v7 inserts at 18,000/sec vs UUID v4 at 4,500/sec on MySQL 8. The 4x difference comes from B-tree indexing: v4 random inserts cause page splits, v7 sequential inserts go to the right side of the tree.
How to generate UUIDs in the browser
The fastest way:
crypto.randomUUID() // → "550e8400-e29b-41d4-a716-446655440000"This returns a UUID v4. For v7, you need a small polyfill combining crypto.getRandomValues with a timestamp prefix.
The UUID generator on DevSpeedTools produces both v4 and v7 in the browser using crypto.getRandomValues directly. Generate one UUID or bulk-generate 100 — no installation, no server, no upload.
Bulk UUID generation
For test data, you often need hundreds or thousands of UUIDs. The browser can generate v4 UUIDs at millions per second using crypto.randomUUID() in a loop. For v7, the timestamp component means you can’t generate more than one per millisecond with guaranteed uniqueness — but the random suffix gives you enough collision resistance for practical purposes.
UUID format variations
Different systems expect different UUID formats:
| Format | Example | Use case |
|---|---|---|
| Standard | 550e8400-e29b-41d4-a716-446655440000 |
Most databases, APIs |
| No dashes | 550e8400e29b41d4a716446655440000 |
Some APIs, URL parameters |
| Upper case | 550E8400-E29B-41D4-A716-446655440000 |
Legacy systems |
| Curly braces | {550e8400-e29b-41d4-a716-446655440000} |
Microsoft GUIDs |
The standard dashed format is the safest default. Most databases and ORMs accept all variants.
Common UUID mistakes
- Using v4 for database primary keys. Random UUIDs kill write performance at scale. Use v7 for new schemas.
- Assuming UUIDs are sequential. v4 is random. v7 is time-ordered but not sequential within a millisecond.
- Storing UUIDs as strings. UUIDs are 16 bytes binary. Storing as a 36-character string wastes 20 bytes per row and slows indexes. Use the native UUID type in Postgres, MySQL 8+, or SQLite with extensions.
- Forgetting the variant bits. UUIDs have variant bits that affect the first hex digit of the third group. Don’t strip them.
Generate UUIDs now
If you need a UUID right now, use a browser-based generator. The UUID generator on DevSpeedTools produces v4 and v7 UUIDs instantly, with copy-to-clipboard and bulk generation. No upload, no account, no server — your UUIDs are generated locally using crypto.getRandomValues.