UUID Generator
Generate version 4 UUIDs using your browser's cryptographically secure random number generator. Single UUID or bulk — up to 1,000 at once.
Where UUIDs are used
Database primary keys
UUIDs as primary keys eliminate coordination between services — each service generates its own IDs without needing a central sequence. Essential for distributed systems and microservices.
Idempotency keys
Payment APIs (Stripe, PayPal) use idempotency keys to prevent duplicate charges when retrying failed requests. Generate a UUID per request and attach it as the idempotency key.
File and object naming
Uploaded files, S3 objects, and temporary files benefit from UUID names — no collisions, no need to sanitize user input, and files are difficult to enumerate by guessing.
Session and correlation IDs
Assign a UUID to each API request or user session for distributed tracing. Pass it as X-Request-ID and log it everywhere — correlate logs across services instantly.
UUID v4 anatomy
Breaking down what each part means
Frequently asked questions
What is UUID v4?
UUID v4 (Universally Unique Identifier, version 4) is a 128-bit identifier generated using random or pseudo-random numbers. It follows the format xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx where the 4 is fixed (version marker) and y is one of 8, 9, a, or b (variant marker). The remaining 122 bits are random.
How unique are UUID v4s really?
Extremely unique in practice. With 122 random bits, there are 2^122 ≈ 5.3×10^36 possible values. The probability of generating a duplicate in 1 billion UUIDs per second for 100 years is about 50% — that's 3×10^21 UUIDs. For all practical applications, collisions are not a concern.
Is this generator cryptographically secure?
Yes. This tool uses crypto.randomUUID() (or crypto.getRandomValues() as a fallback), which is the browser's CSPRNG (cryptographically secure pseudo-random number generator). It's the same source used for TLS key generation and is suitable for security-sensitive use cases.
Should I use UUID as a database primary key?
UUID v4 works as a primary key but has downsides: random ordering causes index fragmentation in B-tree indexes (a problem at scale with PostgreSQL/MySQL), and they're large (16 bytes vs 4 for an integer). For write-heavy tables, consider UUID v7 (ordered by time) or ULID instead. For most applications, UUID v4 is fine.
What's the difference between UUID versions?
v1: time-based + MAC address (exposes machine identity). v3/v5: deterministic, generated by hashing a name + namespace. v4: fully random (most common). v7: time-ordered random (new, better for databases). For new projects that need uniqueness without ordering, v4 is the standard choice.
Related Tools
All conversions run in your browser — nothing is uploaded.
Browse all 26 converters →