UUID Generator (v4 and v7)
Generate random UUID v4 or time-ordered UUID v7 identifiers, one at a time or in bulk. For developers picking primary keys, correlation IDs and idempotency tokens, and deciding which UUID version their database will thank them for.
How to use
- Choose the version: v4 (fully random) or v7 (timestamp-ordered).
- Set how many UUIDs you need.
- Generate and copy the results, one per line.
A UUID is a 128-bit identifier written as 36 characters of hex and hyphens, designed so that anyone can generate one anywhere with effectively no risk of collision, no central registry, no coordination. Version 4 fills 122 bits with pure randomness. You would need to generate about 2.7 quintillion of them to reach a 50% chance of a single collision, which is why code that checks UUIDs for duplicates is wasted effort.
Version 7, standardised in RFC 9562 (2024), changes the layout rather than the guarantee: the first 48 bits are a Unix millisecond timestamp, the rest random. The result still looks like a UUID but sorts by creation time. That single property fixes v4's biggest operational problem, index fragmentation. Random v4 keys scatter inserts across the whole of a B-tree index, causing page splits and cache misses. MySQL and PostgreSQL both suffer measurably at scale. v7 keys append like an auto-increment while remaining globally unique.
Choosing between them is straightforward: v7 for database primary keys, event IDs and anything you'll sort or range-scan by time, v4 when IDs must not leak timing information (password-reset tokens, invite codes, better still, use a dedicated random token). One caveat: a v7 UUID reveals its creation time to anyone who reads it, which is occasionally a privacy consideration. Both versions here come from a cryptographically secure random source, generated fresh per request and never stored.
Examples
Input: version=4, count=1
Output: 9f1b6c1e-3a7d-4c2b-9e4f-8d21a0b7c3f5Input: version=7, count=2
Output: 01981f2e-5a3c-7d1b-8f6a-2c9e4b0d7a31 and 01981f2e-5a41-7b8c-9d2e-6f0a3c8b5e47, note the shared timestamp prefixFrequently asked questions
Should I use UUID v4 or v7 for database primary keys?
v7. Its timestamp prefix means new rows land at the end of the index instead of at random positions, avoiding the page splits and cache churn v4 causes in B-tree indexes. v4 remains fine for low-volume tables and for IDs that must not reveal creation time.
Can two generated UUIDs ever collide?
In theory yes, in practice no. With 122 random bits, generating a billion v4 UUIDs per second for 85 years yields roughly a 50% chance of one collision. Application code should treat UUIDs as unique without checking.
Are UUIDs safe to use as secret tokens?
v4 has 122 bits of CSPRNG randomness, which is unguessable, but UUIDs get logged, cached in URLs and copy-pasted precisely because they look like IDs, not secrets. For security tokens, generate a dedicated random string and treat it like a password.
What happened to UUID v1?
v1 encodes a timestamp plus the machine's MAC address, which leaks hardware identity and caused real privacy incidents. v7 provides the time-ordering benefit without embedding any machine identifier.
Related tools
Velona is India's INR-native AI API gateway with 300+ models, UPI top-up from ₹10, no foreign card needed. These tools are free forever.