UUID Generator
Generate v4 (random) and v7 (time-sorted) UUIDs in bulk.
Pick a version and a count. UUIDs are generated locally with crypto.getRandomValues - no two will ever collide in practice.
How to use it
Pick a version
v4 for general-purpose random IDs; v7 when you'll use the UUID as a database primary key and want time-sortable inserts.
Set the count
Generate one or up to 500 at a time. Each is independent and cryptographically random.
Copy and use
Copy the list and paste it into your code, seed data, or terminal session.
What is it?
A UUID (Universally Unique Identifier) is a 128-bit value designed so that two systems can independently generate IDs without coordinating, and the odds of collision are effectively zero. Version 4 UUIDs are 122 random bits with a fixed version/variant header - perfect when you don't care about ordering. Version 7, standardised in 2024, prepends a 48-bit Unix millisecond timestamp so IDs sort chronologically and play nicely with B-tree indexes.
When to use it
Generate v4 when you need a public-facing opaque identifier (user IDs, file uploads, idempotency keys) and ordering doesn't matter. Generate v7 when you're inserting into a B-tree primary key - chronological ordering keeps the hot region of the index small and dramatically improves write throughput compared to v4 on large tables.
Common mistakes
Don't store UUIDs as strings if you can store them as native uuid or binary(16) - text storage is 2–3× larger and slower to index. Don't use v4 as a PostgreSQL primary key on a high-write table; v7 or ULID is better. And don't roll your own random generator: use crypto.getRandomValues (or crypto.randomUUID) so the output isn't predictable.
FAQ
- Should I use UUID v4 or v7?
- v4 is fully random and great as a primary key when you don't care about ordering. v7 embeds a millisecond timestamp at the start, so v7 IDs sort chronologically - ideal for B-tree primary keys.