Generating 10,000 UUIDs without leaving the browser in 2026

Use crypto.randomUUID() in any modern browser console for quick v4s, and a client-side bulk generator when you need thousands at once or UUID v7 ordering. v4 is 122 random bits. v7 puts a 48-bit Unix timestamp up front, so rows sort by creation time and your database index stays happy. For new primary keys in 2026, default to v7.

Quick disclosure: the UUID generator I link to below is one I built. Back in May I tried seven online generators during a database migration, and every one either capped bulk output at 100, skipped v7 entirely, or buried the copy button under ads. Mine is free and runs entirely client-side. No signup, and nothing you generate ever leaves your machine. If you know a better one, tell me in the comments.

The 11pm seed script that started this

Three weeks ago, on August 5th, I was putting together a demo environment that needed 8,500 fixture rows spread across four tables. The schema uses UUID primary keys, and the fixture data lives in a spreadsheet a teammate on the solutions side maintains. So I needed 8,500 UUIDs in a spreadsheet column before the next morning.

The terminal was my first stop. for i in {1..8500}; do uuidgen; done runs fine, but macOS prints uppercase UUIDs while our snapshot tests normalize everything to lowercase, so the first diff was thousands of lines of pointless noise. Piping through tr '[:upper:]' '[:lower:]' fixed that. Then my teammate had to regenerate two of the tables the next day on a Windows laptop with no WSL, where uuidgen doesn't exist, and my clever one-liner helped nobody. Total damage: 47 minutes on a task that deserved 30 seconds.

There was a second, quieter problem. Those were all v4 UUIDs, which are pure randomness, and random primary keys scatter inserts across the whole index. Each new row lands on a random B-tree page, so caches stay cold and large tables grow bloated indexes. UUID v7, standardized in RFC 9562 back in May 2024, fixes this by putting a millisecond timestamp in the first 48 bits, so new keys always sort after old ones and inserts append instead of scattering. Postgres 18 shipped a native uuidv7() function in September 2025, and at this point I treat v7 as the boring default for any new table.

What surprised me is that most online generators still don't offer v7 at all. That gap is why this article, and the tool it reviews, exists.

What's inside a UUID v7, and how to build one

The layout is simple. First 48 bits: Unix timestamp in milliseconds. Then 4 version bits, 12 random bits, 2 variant bits, and 62 more random bits. That leaves 74 bits of randomness per millisecond, which is plenty for any workload I've ever touched.

Here's a complete v7 implementation that runs in any modern browser console or in Node 19 and newer:

function uuidv7() {
  const bytes = crypto.getRandomValues(new Uint8Array(16));
  const ts = BigInt(Date.now());
  for (let i = 0; i < 6; i++) {
    bytes[i] = Number((ts >> BigInt(40 - i * 8)) & 0xffn);
  }
  bytes[6] = (bytes[6] & 0x0f) | 0x70; // version 7
  bytes[8] = (bytes[8] & 0x3f) | 0x80; // RFC 9562 variant
  const hex = [...bytes].map(b => b.toString(16).padStart(2, "0")).join("");
  return [hex.slice(0, 8), hex.slice(8, 12), hex.slice(12, 16),
          hex.slice(16, 20), hex.slice(20)].join("-");
}

console.log(uuidv7());
// 01a04a2e-9d10-7c3b-a4f2-5b8e19c0d67d

Every v7 you generate this month starts with the same few hex characters (01a0 and change, if you're reading this in August 2026). That's the timestamp doing its job. Sort v7s as plain strings and you've sorted them by creation time, which is the entire trick.

Give or take a counter for ordering within the same millisecond, this is exactly what the generator at aidevhub.io/uuid-generator runs when you click generate. Everything happens client-side; the page never phones home with your output. You pick v4 or v7 and a count up to 10,000, then choose the format: lowercase or uppercase, hyphens or none, plain lines or a JSON array, and braces if you need the old Microsoft GUID registry style. Generating the full 10,000 takes about 40 milliseconds on my 2023 MacBook Air because there's no server round trip. My spreadsheet mess from August is now one copy button.

I'll admit I went back and forth on the bulk cap. 10,000 felt arbitrary. It still does, honestly, but every real use case I collected fit under it, and an unbounded loop in a browser tab is a crash waiting to happen.

How it stacks up against what you already have

You almost never need a website to mint one UUID. The interesting question is what to reach for when you need many of them, or v7 specifically, or a particular output format.

Option	v7 support	Bulk output	Format control	Where it runs
aidevhub UUID Generator	Yes	Up to 10,000	Case, hyphens, braces, JSON	Your browser, client-side
uuidgen (macOS/Linux)	Not on macOS	Shell loop	tr and sed by hand	Local terminal
npm uuid package	Yes (since v10)	Yes, in code	Whatever you write	Node or a bundler
Typical ad-supported sites	Sometimes	Often capped at 100	Rarely	Their server

Inside application code, the npm uuid package is the right answer, full stop. It's supported v7 since version 10 came out in June 2024, and it handles same-millisecond ordering with an internal counter, which my 15-line snippet above doesn't bother with. IDs born in a service should be minted by that service.

uuidgen is great when you're already in a terminal and want one ID. Newer util-linux builds can emit v7, but the macOS version tops out at random v4s (in uppercase, for reasons I've never understood), and a stock Windows machine doesn't ship it at all. Bulk means writing a loop plus a tr pipeline, which is exactly the 47-minute hole I fell into.

The ad-supported generator sites do work. My gripes are the caps (100 per click was the common ceiling when I surveyed seven of them in May), the thin v7 support, and the fact that your IDs get minted on someone else's server. That last one is mostly aesthetic, since a random identifier isn't a secret, though it does rule out offline use and it makes some corporate proxies grumpy.

When a browser generator is the wrong call

Don't pre-generate IDs for production inserts. If your application creates rows, the ID should be minted at insert time by the app or the database, where a library can guarantee uniqueness and monotonic ordering. A static list of UUIDs pasted into production code is a smell. Fixture files and one-off imports are the browser tool's territory; live traffic isn't.

Don't use UUIDs as secrets, either. A v4 has 122 random bits, which sounds like enough, but session tokens deserve a dedicated generator with no structural bits and a shape that secret scanners recognize. And v7 is actively worse for anything sensitive because it embeds its own creation time. Anyone who sees the ID can read when the row was made. I honestly don't know how much that matters for a typical app. My instinct says it's harmless for orders and uploads, and wrong for rows where the creation time is itself private, like medical records. When in doubt there, use v4.

If you need deterministic IDs, where the same input always produces the same UUID, you're looking for v5 with a namespace. That's hashing, and no random generator (mine included) can help you.

And if you work somewhere locked down enough that visiting a web page is a compliance conversation, offline uuidgen is still your friend. The tool keeps working with the network cable pulled, since it's all client-side JavaScript, but I've learned the hard way that policy doesn't always care about implementation details.

FAQ

Q: Do I need to worry about v4 collisions?

A: No. You'd need to generate about 103 trillion v4 UUIDs before the odds of a single duplicate reach one in a billion. If you ever see a real duplicate in the wild, the cause is a bug somewhere, like a copied row or a cloned VM with a frozen entropy pool.

Q: Should I migrate existing v4 primary keys to v7?

A: Almost certainly no. The index-locality win applies to new writes, and rewriting millions of existing keys (plus every foreign key that references them) is a migration with real risk and little payoff. Use v7 for new tables and let the old ones be.

Q: What's the database support story in 2026?

A: Postgres 18 has native uuidv7(). Older Postgres versions store v7 in the regular uuid type without complaint, so generate the values in your application. MySQL's UUID() still emits v1, so there you'd generate v7 in code as well.

Q: Is a GUID different from a UUID?

A: Same 128 bits. GUID is Microsoft's older name for it, traditionally printed uppercase inside braces, which is why the format controls include a braces option.

Written with AI assistance and human review. Try the tool at aidevhub.io/uuid-generator.

Comments

[anassBld]

The shift to UUIDv7 is one of the cleanest database performance wins in recent years.

With UUIDv4, the completely random distribution wrecks B-tree index locality on high-throughput write workloads — you get constant leaf page splits, buffer pool churn, and heavy write amplification. With UUIDv7, having the millisecond timestamp embedded in the leading 48 bits gives you sequential monotonic append behavior while keeping collision-free distributed generation intact.