UUID Generator
Generate UUID v4 (random) or v7 (time-sortable) — in bulk with copy support.
How to Use
- Pick the UUID version: v4 for fully random, v7 for time-sortable, or Nil for all zeros.
- Choose how many UUIDs to generate at once (1–500).
- Optionally enable UPPERCASE for hex digits or {braces} for the Microsoft GUID format.
- Click Generate to create the batch — each UUID is cryptographically random where applicable.
- Click any row to copy that UUID to your clipboard, or use "Copy all" for the entire list.
- Generation is instant and runs entirely in your browser.
UUID Versions
A Brief History of the UUID
UUIDs trace back to Apollo Computer's Network Computing System in the early 1980s, where the company needed identifiers that could be generated independently across many machines without central coordination. The original 128-bit format combined a timestamp with the host's network address — what later became "version 1." The Open Software Foundation's Distributed Computing Environment (DCE) standardized the format in the late 1980s, and Microsoft adopted it as the GUID format in COM and DCOM in the early 1990s.
The IETF formalized the format in RFC 4122 in 2005, defining versions 1 through 5. Version 4 (random) became the dominant form in practice because it requires no host-specific state and exposes no metadata. As databases scaled into the 2010s, however, the random distribution of v4 UUIDs caused B-tree index fragmentation that made them painful as primary keys at scale. That motivated a series of "k-sortable" UUID variants — Twitter's Snowflake, ULID (2016), and finally the IETF's RFC 9562 in May 2024 which standardized UUIDs versions 6, 7, and 8.
Today UUID v7 is becoming the recommended default for new applications: distributed-friendly like v4, but with a timestamp prefix that keeps related rows close together in storage. Major databases (PostgreSQL, MySQL 8.0+) have native UUID types, and many ORMs and frameworks have updated their default ID strategies to v7. Forty years after Apollo's original design, the format keeps evolving — but the 128-bit core hasn't changed.
About This Generator
This generator uses your browser's crypto.getRandomValues for cryptographically-secure randomness. v4 UUIDs are 122 bits of CSPRNG output with the appropriate version and variant bits set. v7 UUIDs use the current Unix millisecond timestamp in the high 48 bits, the version nibble, 12 bits of randomness, the variant bits, and 62 more random bits — matching the RFC 9562 layout exactly. The Nil UUID is the canonical all-zeros placeholder.
UPPERCASE and {braces} options let you match common formatting variants (Microsoft GUIDs, certain configuration formats). Generation runs entirely in your browser; no UUIDs are transmitted, logged, or stored — every batch is local to your session.
Frequently Asked Questions
What's the difference between UUID v4 and v7?
v4 is 122 bits of pure random data formatted as a 36-character string. v7 (RFC 9562, 2024) embeds a 48-bit Unix millisecond timestamp in the high bits, with random bits filling the rest. Two consequences: v7 UUIDs generated in order also sort lexicographically in order, and they cluster near each other in time — both properties make v7 dramatically better as a primary key in many database systems where v4's randomness causes index-fragmentation issues.
Are UUIDs guaranteed unique?
Effectively yes for v4. The pool size is 2<sup>122</sup> (about 5×10<sup>36</sup>), so the probability of collision is vanishingly small even at extreme generation rates. You'd need to generate 1 billion UUIDs per second for 85 years to have a 50% chance of one collision. v7 has a smaller random space per millisecond but the timestamp keeps batches separate, making collision probability similarly negligible in practice.
When should I use UUIDs vs. auto-increment IDs?
UUIDs: distributed systems where multiple nodes generate IDs without coordination, anywhere you don't want sequential IDs leaking information (user enumeration, order counts), and any system where IDs are exposed publicly. Auto-increment: small single-database systems where the index efficiency and human readability of small integers matter more than distribution. Modern advice often defaults to UUID v7 as a hybrid: distributed-friendly but time-sortable.
What's GUID vs UUID?
Same thing, different name. UUID is the IETF/ISO term (RFC 4122 and now 9562). GUID is the Microsoft term, almost universally formatted with curly braces: {550e8400-e29b-41d4-a716-446655440000}. Convert by adding/removing braces.
Should I store UUIDs as strings or binary?
Binary is much more compact (16 bytes vs 36 chars) and faster to index, but harder to debug. Most major databases have native UUID types: PostgreSQL UUID, MySQL BINARY(16), SQL Server UNIQUEIDENTIFIER. Use those rather than VARCHAR(36) for production tables — the storage and index improvements are significant at scale.
Are UUIDs cryptographically secure random IDs?
v4 UUIDs from a properly seeded crypto RNG (this tool uses crypto.getRandomValues) are unguessable in any practical sense. They are good for unguessable resource references (download links, session IDs in some designs). They are NOT suitable for password tokens or anything where the full randomness budget matters — use a dedicated cryptographic token (32+ random bytes encoded as base64url) for those cases.
Common Use Cases
Database primary keys
Replace auto-increment integers with v7 UUIDs to support distributed writes, prevent ID enumeration, and keep B-tree indexes well-clustered.
Distributed system IDs
Generate stable identifiers in microservices, message queues, or event-sourced systems without a central coordinator.
Test data fixtures
Bulk-create realistic-looking IDs for unit tests, integration tests, or fixture seed data.
API request correlation IDs
Tag each incoming request with a UUID so logs across multiple services can be joined later for tracing.
File and asset names
Generate unguessable filenames for user uploads, content-addressable assets, or temporary storage paths.
Idempotency keys
Provide UUIDs as idempotency tokens for non-idempotent API calls so retries are safe.
Last updated: