PDFFlare
8 min read

How to Generate UUID Online (v4, v7, and Bulk Guide)

You need a UUID. Or twenty. Or a thousand. Most engineers generate UUID online by hitting any random tool, copying a stream of v4 values, and moving on with the day. That works for ninety percent of cases — but the remaining ten percent are exactly where engineers waste time fighting their database, debugging a deterministic ID mismatch, or chasing a perfectly avoidable index-locality performance problem. The version of UUID you generate matters more than most people realize.

In this guide you'll learn how to generate UUIDs online using PDFFlare's UUID Generator — every standards-compliant version (v1, v3, v4, v5, v7, plus the Nil and Max sentinels from RFC 9562), bulk-generation up to 1000 at a time, and five output formats. We'll cover which version to use when, why v7 is the modern recommendation for database primary keys, and how to avoid the small mistakes that turn UUIDs from a useful primitive into a debugging headache.

What Is a UUID, Really?

A UUID — Universally Unique Identifier — is a 128-bit number used to label things in distributed systems without coordination. The format you see (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) is just a hexadecimal rendering of those 128 bits broken into five groups for readability. The whole point of the format is that two systems can independently generate UUIDs and statistically never collide — no central counter, no sequence service, no coordination overhead.

Where it gets interesting: those 128 bits aren't all random. The format reserves 4 bits for a version number and 2 bits for a variant flag — leaving 122 bits for the actual identifying content. What goes in those 122 bits depends on the version, and the version is what determines whether the UUID is random, time-ordered, derived from a name, or just a time-based legacy artifact.

The two relevant standards are RFC 4122 (which defined v1, v3, v4, and v5 in 2005) and RFC 9562 (which added v6, v7, and v8 in 2024). Most production code today uses v4 (random); modern systems are increasingly adopting v7 (time-ordered) for database primary keys.

UUID Versions Explained (v1 vs v4 vs v5 vs v7)

Each UUID version solves a different problem. Pick wrong and you pay for it later in performance, security, or determinism. Here's the practical guide:

  • v1 — time-based. 60-bit timestamp + 14-bit clock sequence + 48-bit node ID (originally a MAC address, now usually a random number). Sortable by creation time, but leaks timing information and historically leaked MAC addresses. Mostly legacy.
  • v3 — namespace + MD5.Deterministic from a (namespace UUID, name string) pair, hashed with MD5. Same inputs always produce the same output. MD5 is broken cryptographically but UUID generation doesn't need cryptographic strength — v3 still works fine for non-security use.
  • v4 — random. 122 bits of cryptographic randomness. The default for almost everything. No metadata leakage, no coordination needed. Collision probability is astronomically low.
  • v5 — namespace + SHA-1.Same idea as v3 but with SHA-1. Modern alternative to v3 — prefer v5 unless you're matching a legacy schema that uses v3.
  • v7 — time-ordered. 48-bit Unix-millisecond timestamp + 74 bits random. Recent (RFC 9562, 2024). Sorts chronologically, gives B-tree indexes much better locality. The modern recommendation for database primary keys.
  • Nil and Max.Sentinel values (00000000-... and ffffffff-...). Not real UUIDs — used as placeholders, “unset” markers, or range bounds.

When to Use UUID v7 Over v4

The reason v7 exists is to fix a real performance problem with v4 in databases: random insert order. When your primary key is v4, every new row lands at a random position in the B-tree index. The page that needs to absorb the insert may not be in the cache, forcing a disk read. The page may need to split if it's full, slowing writes. Multiple inserts to the same page invalidate the cache for everyone reading that page.

v7 fixes all of this. Because the timestamp prefix means newer rows always sort after older ones, sequential inserts land near each other in the B-tree. The same handful of pages stays hot in cache, page splits are rare, write throughput goes way up. Postgres and MySQL benchmarks consistently show 5-10× write performance improvement when switching from v4 to v7 PKs at high insert rates.

The trade-off: v7 leaks creation time. If creation time is sensitive (medical records, security tokens), use v4 anyway — the performance hit is real but it's the right call. For everything else (orders, events, log records), v7 is now the right default.

Using a v4 UUID generator for tokens and request IDs

Even with v7 taking over for primary keys, a v4 UUID generator stays the right tool for any identifier where you'd rather notembed creation time: API keys, password reset tokens, session IDs, magic-link tokens, request IDs that end up in third-party logs. v4's 122 bits of pure randomness mean an attacker who sees one of your IDs cannot predict the next, the previous, or anything about when it was minted. That's the security property you're paying for.

UUID v5 namespace UUIDs for deterministic IDs

v5 is the right answer when two systems need to compute the same UUID for the same logical input without coordinating. A uuid v5 namespace pair (one of DNS, URL, OID, X.500, or a custom namespace UUID) plus a name string deterministically produces a UUID via SHA-1 hashing. Every system with the same namespace + name gets the same UUID — which makes v5 ideal for content-addressed IDs, idempotency keys, and any situation where “the same input must always produce the same identifier” is a hard requirement.

How to Generate UUID Online with PDFFlare

Step-by-step using PDFFlare's UUID Generator:

  1. Pick a version from the dropdown. Default is v4. Pick v7 for database keys, v5 for deterministic IDs, v1 for legacy compatibility.
  2. For v3 or v5, also pick a namespace (DNS, URL, OID, X.500, or a custom UUID) and enter the name string. The same (namespace, name) pair always produces the same UUID.
  3. Set the count from 1 to 1000. The slider and numeric input both work — pick whichever feels natural.
  4. Pick output format: hyphenated (default), no-hyphens, UPPERCASE, brace-wrapped (Microsoft style), or URL-safe base64. UUIDs regenerate live as you change settings.
  5. Copyany individual UUID with the per-row Copy button, or use “Copy all” to grab the entire list as newline-separated text. Settings persist across sessions, so the next visit defaults to your last configuration.

Bulk-Generating UUIDs for Seed Data

The bulk mode is where the tool earns its keep for developers. A few common workflows:

  • Database fixtures: seed your dev/staging DB with 100-1000 records, each needing a stable UUID. Set count to 1000, copy all, paste into a SQL INSERT statement (or pipe through JSON to SQL after combining with your other fixture data).
  • Load testing: generate 1000 v7 UUIDs to simulate a realistic write workload that respects insert ordering.
  • Mock API responses: when stubbing out a service, you need a batch of plausible-looking IDs. Bulk v4 generation gives you a copy-paste-able list.
  • Unit tests:deterministic v5 UUIDs make assertions easy — test “does this function produce the expected UUID for input X” without flakiness.

Bulk UUID generator: 1, 100, or 1000 at a time

A good bulk uuid generator removes friction at exactly the point developers feel it: fixture creation, load-test data, and one-off scripts where you need a hundred valid IDs and you do not want to write a loop, install a CLI, or paste a python -c into your shell. Set the count, pick the version, hit copy-all. Settings persist across visits, so the next time you need 250 v7 UUIDs the tool already remembers you wanted v7 and the URL-safe base64 format.

Common UUID Mistakes (And How to Avoid Them)

  1. Storing UUIDs as VARCHAR(36). A UUID is 16 bytes. VARCHAR(36) is 36+ bytes. Postgres has a native uuid type; MySQL has BINARY(16); both are 2-3× faster for indexing and use less memory. Always use the binary type.
  2. Using Math.random() to generate UUIDs. Math.random() is predictable — anyone who sees a few of your UUIDs can predict the next one. Always use the platform CSPRNG: crypto.getRandomValues in browsers, crypto.randomUUID in Node 14.17+,os.urandom in Python.
  3. Treating v4 collision as “possible”. 122 bits of randomness gives you ~5.3×10^36 possible v4 UUIDs. Even at one billion UUIDs generated per second forever, the expected time to a single collision is on the order of 85 years. You don't need to handle the collision case — but you DO need to use the CSPRNG.
  4. Mixing UUID versions in the same table. Generally fine, but if you mix v4 and v7 as primary keys, you lose v7's index-locality benefit. Pick one version per identifier role and stick with it.
  5. Trying to use the Nil UUID as a real ID. 00000000-... is reserved as a sentinel. Many libraries treat it as “unset.” If you accidentally persist Nil as a real entity ID, downstream code may treat those rows as missing.
  6. Generating UUIDs in a tight loop without seeding.Some legacy libraries used a per-process seed that got fixed at startup; if your process forks before generating IDs, every child can produce identical UUID sequences. Modern CSPRNG-based generation (including PDFFlare's) reads fresh entropy on every call, so this is no longer a concern — but if you're on an older runtime, verify the library you use.
  7. Confusing UUID with GUID.They're the same thing — “GUID” is Microsoft's name for “UUID.” If a Windows-flavored doc tells you to generate a GUID, paste a UUID. The brace-wrapped output format ({xxx-xxx-...}) is the only place the distinction shows up — that's a Microsoft display convention, not a different value.

UUID generator vs GUID generator: same tool, different name

Searching for a guid generator and a uuid generator returns the same kind of tool because the underlying value is identical: 128 random bits formatted as a hyphenated hex string. Microsoft's GUID format wraps the value in curly braces ({xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}) for Registry, COM, and .NET interop; everywhere else the same value is unwrapped. PDFFlare's tool exposes a brace-wrapped output format precisely so the same generator serves both audiences without translation. Pick brace-wrapped if you're pasting into a Windows config; pick hyphenated for everything else.

Privacy: Are Online UUID Generators Safe?

The fundamental concern with any online generator is whether the tool sees your generated values. PDFFlare's UUID generator runs entirely in your browser — your machine's crypto.getRandomValues() provides every random byte for v4 and v7, and crypto.subtle.digest() handles SHA-1 for v5. Nothing uploads, nothing logs, nothing analytics.

That matters for a few specific use cases:

  • Generating IDs that become secret tokens (API keys, password reset tokens, magic-link IDs). Any third-party that sees these values can use them. Local generation keeps them local.
  • Generating IDs for an internal systemthat you don't want correlated with your IP via a third-party log.
  • Generating large batches where round-trip latency would dominate the time. Local generation is instant.

For everyday use cases (test data, mock IDs, debugging), it probably doesn't matter — but defaults that respect privacy mean you don't have to think about it. Pair this generator with Hash Generator when you need to derive deterministic hashes from your UUIDs, or with Base64 Encode/Decode when downstream systems need the URL-safe base64 form.

Related Tools

  • Hash Generator — compute MD5, SHA-1, SHA-256, and SHA-512 hashes of any text. Useful when you need a deterministic fingerprint of a UUID payload, or to verify v3/v5 outputs against an independent reference.
  • Base64 Encode / Decode — encode UUIDs to URL-safe base64 for compact tokens, or decode back to canonical form. Pairs with the URL-safe base64 output format in the UUID generator.
  • JWT Decoder — inspect JSON Web Tokens, including the jti(JWT ID) claim that's almost always a UUID. Verify your generated UUIDs survive a round-trip through your auth layer.
  • URL Encode / Decode — escape UUID-shaped path segments and query parameters for safe inclusion in URLs without ambiguity over reserved characters.

Wrapping Up

UUID generation looks trivial until you realize the version you pick has direct downstream consequences for performance, determinism, and security. v4 is the safe default for most uses. v7 is the modern recommendation for database primary keys. v5 is the right call for deterministic IDs. v1 should stay in legacy systems. Pick deliberately and the rest of your stack runs better — pick by accident and you'll revisit it as a performance regression six months later.

Generate your next batch with PDFFlare's UUID Generator — every version, five output formats, 1-1000 at a time, all in your browser with cryptographic randomness. No signup, no watermarks, no API quota. Just UUIDs.

Back to all posts