About UUID Generator
Generate v1 (time + MAC), v4 (random), and v7 (time-ordered) UUIDs. Pick the count (1-1000), the format (dashes / no dashes / uppercase / braces), and download or copy the lot. v7 produces sortable, time-prefixed IDs that index well as database primary keys without leaking creation order through the surface.
Why UUIDs exist
A UUID is 128 bits chosen so two parties can independently generate identifiers without coordination and have effectively zero chance of collision. They are bigger than auto-increment integers, but they let you mint IDs offline, before a database round-trip, in any process, on any machine — useful in distributed systems, batch imports, and offline clients.
The versions, briefly
- v1 — timestamp + MAC address. Sortable but leaks where and when you generated it. Avoid.
- v4 — 122 random bits. Opaque, unsortable, the historical default.
- v6 — v1 reordered to sort. Niche.
- v7 — millisecond timestamp + random tail. Sortable, no MAC leak. Use this for database keys.
- v8 — custom-format, application-defined. Reserved for special cases.
If you are picking one in 2025: v7 for database primary keys, v4 for opaque public IDs.
Format options
- With dashes —
f47ac10b-58cc-4372-a567-0e02b2c3d479(canonical) - Without dashes —
f47ac10b58cc4372a5670e02b2c3d479(compact, common in URLs) - Uppercase — for systems that expect it
- Braces —
{f47ac10b-58cc-4372-a567-0e02b2c3d479}(Microsoft-style) - Base32 / Base64 — short opaque tokens (24 / 22 chars)
Common workflows
Seed test data. Generate 1000 v7 UUIDs, paste into your fixture, watch your tests sort the same way production will.
Migrate from auto-increment to UUID v7. Generate a starting batch, plan the dual-write cutover. The time-ordered property keeps your indexes happy through the migration.
Mint stable identifiers offline. Generate IDs in a browser-side form before submit. Idempotent retries become trivial — same UUID, same record.
Why v7 is winning
For ten years, the industry’s split was “Postgres BIGINT for hot tables, UUID v4 for distributed keys, accept that v4 fragments your B-tree.” v7 ends that compromise. You get distributed generation and sequential storage. No clustering surgery, no random-page churn, no covering indexes built around created_at. Most teams that move greenfield work to v7 do not look back.
Frequently asked questions
Which UUID version should I use?
Is v7 standardized?
UUID.gen7, npm uuid@10).Are these UUIDs cryptographically random?
crypto.getRandomValues for the random portion. Per RFC 9562, that is sufficient for primary-key uniqueness. For tokens that must resist guessing, prefer a cryptographic random string from the Random String tool.How many can I generate at once?
Are UUIDs collision-safe?
Why do my v7 UUIDs all start with similar characters?
Related tools
Last updated: 2025-01-15