UUID Generator (v4)
Generate cryptographically random UUID v4 values in bulk. Copy one or the whole batch — all in your browser.
- Runs in your browser
- No upload, no tracking
- Free forever
How it works
A UUID v4 generator produces 128-bit universally unique identifiers from cryptographically random data — 122 of those bits are random, making collisions effectively impossible without any central coordinator. They are widely used as database primary keys, request IDs and idempotency keys. This tool runs entirely client-side using the browser's Web Crypto API, so nothing is transmitted. It is built by JusDB, a managed database operations team, for the identifier work that surrounds every schema.
- 1
Choose how many
Enter a count from 1 to 1000 in the ‘How many’ field. The page generates an initial batch on load.
- 2
Generate
Click Generate to produce a fresh batch of cryptographically random UUID v4 values.
- 3
Copy what you need
Copy any single UUID from its row, or use ‘Copy all’ to grab the entire list as newline-separated values.
Frequently asked questions
- What is a UUID v4?
- A UUID v4 is a 128-bit universally unique identifier generated from random data. With 122 random bits, collisions are astronomically unlikely, which makes them ideal as primary keys, request IDs and idempotency keys.
- Are these UUIDs cryptographically random?
- Yes. The generator uses the browser's Web Crypto API (crypto.randomUUID or crypto.getRandomValues), which is a cryptographically secure source of randomness.
- Is anything sent to a server?
- No. UUIDs are generated locally in your browser. Nothing is transmitted to JusDB or any third party.
- How many can I generate at once?
- From 1 up to 1000 per batch. Set the count, click Generate, then use ‘Copy all’ to grab the whole list as newline-separated values, or copy any single UUID from its row.
- What is the difference between UUID v4 and other versions?
- v4 is purely random, while v1 embeds a timestamp and MAC address and v7 embeds a time-ordered prefix. This tool generates v4, which is the most common choice when you simply need a unique value with no ordering or host information leaked.
- Are UUID v4 values good database primary keys?
- They guarantee uniqueness without a central coordinator, which is useful for distributed systems. Be aware that random UUIDs can fragment B-tree indexes; for insert-heavy tables, time-ordered IDs (like UUID v7) or sequential keys often perform better.
UUID versions, database keys & index performance
"UUID" is not one format but a family of versioned 128-bit identifiers, and the version you pick has real consequences once these values become primary keys. This tool emits v4, but understanding v1, v4 and v7 helps you decide what to actually store in your schema.
v1 vs v4 vs v7
Version 1 packs a 60-bit timestamp and the host MAC address into the identifier, which makes values roughly time-ordered but leaks the generating machine. Version 4 is pure randomness (122 random bits) and leaks nothing, which is why it is the safe default for tokens and externally visible IDs. Version 7, standardized in RFC 9562, leads with a Unix-millisecond timestamp followed by random bits — so the values are both unguessable and naturally sortable by creation time. For new database keys, v7 is now the modern recommendation.
Why random UUIDs hurt your index
The case against v4 as a primary key is not uniqueness — it is locality. Database indexes are B-trees, and inserting in sorted order means new rows land on the right-most page that is already hot in memory. Random v4 values scatter inserts across the whole keyspace, so every insert can dirty a different page, evict cache, and trigger page splits as full pages make room for a mid-range key. In MySQL/InnoDB the table is physically clustered on the primary key, so a random PK reorders the entire row storage and bloats secondary indexes (which carry a copy of the PK). The effect is milder in PostgreSQL because the heap is not clustered, but the index itself still fragments and write amplification climbs. Time-ordered v7 (or a ULID) restores append-mostly insert behavior and largely removes the penalty — see our PostgreSQL performance tuning playbook for the broader index picture.
Store them as 16 bytes, not 36 characters
However you generate them, store UUIDs in a native binary form. PostgreSQL has a real uuid type that uses 16 bytes; MySQL should use BINARY(16) (often paired with UUID_TO_BIN()). Persisting the canonical text as CHAR(36) wastes well over 2x the space per key, inflates every index that references it, and slows comparisons. The storage choice matters as much in MySQL as the version choice does.
Worried about collisions? With 122 random bits you would need to generate on the order of a billion v4 UUIDs per second for about 85 years before reaching a 50% chance of a single duplicate. In practice your bottleneck is index layout, not uniqueness — so optimize for insert locality, not for collision odds.