UUID Generator

Click Generate UUID to create a UUID

About the UUID Generator

The UUID Generator produces v1, v3, v4, v5, and v7 UUIDs — all in your browser, all backed by `crypto.getRandomValues` for randomness. v4 and v7 are the modern defaults: v4 is purely random (still the most common database primary key choice), v7 is time-ordered (per RFC 9562, ratified in 2024) and gives much better B-tree index locality. v3 and v5 produce deterministic UUIDs from a namespace and a name — useful for stable IDs derived from URLs or string keys. Bulk generation supports up to 10,000 UUIDs at once. No randomness, secrets, or generated values touch any server.

Updated: May 8, 2026

Related Tools

Hash Generatorv3/v5 use MD5/SHA-1 — the hash generator computes the same digests for verification.Try it JSON ViewerBulk-generated UUIDs often go straight into JSON test fixtures.Try it JWT DecoderJWT `jti` (JWT ID) claim is typically a v4 UUID.Try it QR Code GeneratorEncode a UUID into a QR code for asset tagging or invitation links.Try it Base64 EncoderUUIDs can be packed into 22-char Base64URL strings — encode here for compact transports.Try it

How to use the UUID generator

  • Pick a version: v4 (random — the default), v7 (time-ordered random), v1 (timestamp + node ID), or v3/v5 (deterministic from a name in a namespace).
  • For v3/v5, paste a namespace UUID (the spec defines four standard namespaces: DNS, URL, OID, X.500) and a name; the same namespace+name always produces the same UUID.
  • Set the count (1 - 10,000). The generator runs synchronously for small counts and uses `requestIdleCallback` for larger batches so the page stays responsive.
  • Copy a single UUID with one click, or use Copy All to grab the entire batch as a newline-separated list.
  • Optionally toggle uppercase output, hyphen suppression, or curly-brace wrapping (`{...}`) for legacy systems that expect those formats.

Common use cases

  • Database primary keys. v4 is collision-resistant enough for any practical database (the probability of a collision among 1 billion UUIDs is roughly 1 in 18 quintillion). v7 is the better choice for most new schemas because its time-ordered prefix gives B-tree indexes much better insert locality than v4.
  • Distributed system request IDs. Stamp every incoming request with a v4 or v7 UUID; carry it through logs, metrics, and span IDs. v7 has the bonus property that you can sort logs by request-ID and they come out in time order.
  • Idempotency tokens. Stripe, AWS, and many SaaS APIs accept an `Idempotency-Key` header to deduplicate retries. v4 is the canonical generator.
  • Test fixture generation. Bulk generate 100-1000 UUIDs to seed a test database; the deterministic v5 variant lets you produce the same UUID every time from a stable input (`v5(NS_URL, "https://example.com/user/42")`).
  • Stable identifiers from external strings. v5 lets you derive a UUID from a URL, a tenant slug, or a SKU — handy for migrations and for systems that need a UUID format but already have a natural key.

Privacy and security

Random-byte generation routes through `crypto.getRandomValues`, the browser CSPRNG (cryptographically-secure pseudorandom number generator). v3 / v5 hashing uses MD5 / SHA-1 respectively (per the spec; both are fine for namespace hashing because no security claim depends on the hash being collision-resistant — the namespace+name uniquely determines the UUID). Nothing is sent to any server; bulk batches up to 10,000 UUIDs are generated locally without network access.

Tips and pitfalls

  • v4 vs v7 for new databases. v4 randomness destroys B-tree index locality — each insert hits a random page, killing buffer-pool hit rates on large tables. v7 time-orders the high bits, so inserts cluster into the most recent pages. For new schemas in 2026, default to v7.
  • v1 leaks the MAC address. v1 includes the node's MAC address (or a random pseudo-MAC, depending on the generator); never use v1 for security-sensitive identifiers like password reset tokens or invitation codes.
  • v3 uses MD5, v5 uses SHA-1. Both algorithms are cryptographically broken for collision resistance, but UUID namespaces do not depend on collision resistance — so v3/v5 are fine in practice. Prefer v5 for new systems anyway, since SHA-1 is harder to attack.
  • 128 bits is enough for almost any application. By the birthday bound you would need to generate roughly 2.3 × 10^18 (2.3 quintillion) v4 UUIDs before having a 50% chance of any collision. For most applications this is irrelevant; for keys that aggregate across a large number of independent producers (IoT fleets, multi-tenant SaaS), still think carefully about your collision budget — randomness quality and producer independence matter more than the raw bit count.
  • ULIDs are an alternative. ULIDs are 128-bit, time-ordered, and lexicographically sortable as strings (Crockford Base32). They predate v7 by several years and remain a reasonable choice for systems that already use them.

Frequently Asked Questions

v4 vs v7 — which should I use in 2026?
For new databases, prefer v7. The time-ordered high bits dramatically improve B-tree insert locality, which keeps buffer-pool hit rates high on large tables. v4 is still fine for short-lived tokens, idempotency keys, and anywhere insert order does not matter.
What is the collision probability of v4?
Roughly 1 in 5.3 × 10^36 for a single pair of v4 UUIDs (122 random bits). By the birthday bound, you would need to generate ~2.3 × 10^18 UUIDs (about 2.3 quintillion) before having a 50% chance of any collision. For practical applications this is "never".
How do v3 and v5 differ?
Both produce deterministic UUIDs from a namespace UUID and a name string. v3 hashes with MD5, v5 with SHA-1. Both are cryptographically dated, but UUID namespacing does not depend on cryptographic collision resistance — so the choice is mostly about which one your existing ecosystem uses. New projects should pick v5.
What is the difference between RFC 4122 and RFC 9562?
RFC 4122 (2005) defined v1-v5. RFC 9562 (May 2024) replaced and updated it, formally specifying v6 (rearranged v1) and v7 (Unix-timestamp-prefixed) and clarifying ambiguities in the original spec. v7 is the practical takeaway — most new application code that previously used v4 should switch.
Are the UUIDs cryptographically secure?
Yes — the random portions come from `crypto.getRandomValues`, which is a CSPRNG. Use them for tokens that need to be unguessable. The deterministic versions (v3, v5) are only as unpredictable as the namespace+name input — do not use them for tokens.
UUID vs ULID — which is better?
ULIDs are 128 bits (same as UUID), time-ordered, and string-sortable in Crockford Base32 — a big readability win. UUID v7 covers most of the same use cases with a more standard format. Use ULIDs in greenfield projects that need the string-sort property; use UUID v7 when you need the standard hyphenated 36-character format.
Are UUIDs good database primary keys?
For OLTP workloads with high insert rates: v4 hurts B-tree locality (consider v7 instead) but lets you generate IDs client-side without a database round-trip. For OLAP / analytics: integer keys are denser and faster. Trade-offs are well-documented; the answer depends on your workload.
Is there a maximum count for bulk generation?
The UI caps bulk generation at 10,000 to keep the page responsive. For larger batches use a command-line tool (`uuidgen`, `python -c "import uuid; print(uuid.uuid4())"`) or a one-liner in your application code.
Where can I read the full specification?
RFC 9562 is the current authoritative spec. RFC 4122 is the historical predecessor. The Wikipedia UUID article is a good readable summary. The IETF dispatch draft (`draft-peabody-dispatch-new-uuid-format-04`) was the v6 / v7 working draft that fed into RFC 9562.