Corvo

Generators

UUID Generator

Generate v4 or v7 UUIDs one at a time or in bulk, up to 1,000 at once. Copy or download as plain text. Runs locally in your browser.

Runs entirely in your browser. Nothing is uploaded.

00000000-0000-4000-8000-000000000000
Ready

What this tool does

Generates one or many UUIDs — v4 (random) or v7 (time-ordered) — with control over case, hyphens, and wrapping, ready to paste straight into code, a config file, or a spreadsheet. Bulk generation goes up to 1,000 at once, with a plain-text download for anything larger than you'd want to copy by hand.

How to use it

  1. Pick a version. v4 is the sensible default; use v7 if these are heading into a database primary key.
  2. Set a quantity — leave it at 1 for a single UUID, or raise it for a bulk batch.
  3. Adjust formatting if needed: uppercase, no hyphens, or wrapped in braces or quotes for pasting directly into code.
  4. Copy, or download the batch as a plain text file.

Choosing a version

Reach for v4 by default — it's the most widely recognized format and the right choice whenever there's no specific reason to want anything else: API keys, session identifiers, file names, test fixtures.

Reach for v7 specifically when the UUID is going to be a database primary key, or anywhere else that benefits from sorting roughly by creation time. Because the timestamp sits in the first 48 bits, v7 values generated later always sort after earlier ones as plain strings — useful for keeping an index's insert pattern sequential rather than scattered, and handy any time you want to eyeball a list of IDs and see which came first without a separate timestamp column.

A note on bulk generation

Every UUID in a batch is generated independently with its own fresh randomness — batching doesn't trade away any uniqueness guarantees. The 1,000-per-batch cap here isn't a technical limit (this could technically generate far more) — it's simply more than almost any real task needs in one pass, and keeps the page responsive rather than trying to render an unreasonably long list.

Questions

What is a UUID?

A Universally Unique Identifier — a 128-bit value, usually written as 32 hex digits split into five groups, designed so that anyone, anywhere, can generate one without checking with a central authority and still end up with something that's never been generated before. Used constantly as database primary keys, request IDs, session tokens, and file names that need to be unique without coordination.

What's the difference between v4 and v7?

v4 is almost entirely random — 122 bits of it. Simple, and the long-time default. v7 (finalized as a standard in 2024) puts a millisecond timestamp in the first 48 bits and fills the rest with randomness, which means v7 UUIDs generated later always sort after ones generated earlier, as plain strings. That property makes v7 noticeably better as a database primary key: inserts land in roughly the same physical location in the table's index rather than being scattered randomly, which matters for large tables. If you don't have a specific reason to want time-ordering, v4 remains a perfectly good default.

Could two generated UUIDs ever collide?

In practical terms, no. A v4 UUID has 122 random bits — to have even a 50% chance of one collision, you'd need to generate somewhere around 2.7 quintillion of them. You will run out of reasons to generate UUIDs long before that becomes a real risk.

Is the randomness here actually secure?

Yes. v4 uses the browser's own crypto.randomUUID(), and v7's random portion uses crypto.getRandomValues() — the same cryptographically secure source, not Math.random(). Nothing generated here is predictable.

What happened to v1, v2, v3, and v5?

v1 encodes a timestamp and, traditionally, the generating computer's MAC address — a real privacy leak, which is why it's fallen out of favor. v3 and v5 are deterministic: the same namespace and name always produce the same UUID, which is a genuinely different tool for a genuinely different job (matching, not generating unique identifiers) rather than something this page is built around. v2 is rare enough in practice that almost nothing generates or expects it. v4 and v7 cover what the overwhelming majority of real use cases need.

Can I use these as database primary keys?

Yes, and v7 is a genuinely good choice for it specifically — the time-ordering keeps new rows physically close together in most database index structures, which is kinder to performance at scale than the effectively-random insert order v4 produces. Several databases (PostgreSQL among them) have moved toward recommending v7-like keys for exactly this reason.

Related tools