UUID Generator

The whole point is not asking permission

A UUID is 128 bits of identifier you can mint without phoning some central server to ask for the next number in line. Look, that's the entire trick. Two services can both create a record at the exact same millisecond and nobody fights over an ID. Handy for APIs, event logs, import jobs, drafts on the client that haven't hit the server yet. They also keep you from leaking tidy little sequential numbers in public URLs (your competitor counting your order IDs, that kind of thing), though please don't mistake that for actual access control. It isn't.

This generator does the two versions you'll actually reach for. v4 is plain random and supported basically everywhere. v7 is time-ordered, which databases and log systems tend to like, because fresh values roughly sort themselves by when you made them. Beyond spitting out IDs, it validates whatever you paste, swallows the URN and braces and no-hyphen variants, shows you the version and variant bits, exports as newline text or CSV or a JSON array, and talks through collision odds without the math-textbook tone.

UUID v4 or UUID v7?

Reach for v4 when you just want a solid general-purpose random ID and your stack already speaks it. Go v7 the moment sort order starts mattering to you: audit logs, queue records, anything where you're constantly pulling the most recent rows. Neither one is a secret, by the way, and I'll keep saying it because people keep forgetting. Somebody knowing a UUID means nothing. Your auth rules still have to check whether they're allowed to read or change that record.

• UUID v4 is just random. Generate it correctly and a collision is wildly improbable.
• UUID v7 leads with a timestamp, then fills the rest with randomness, so it sorts by time without any extra work from you.
• Canonical format is lowercase with hyphens, those 8-4-4-4-12 hex groups everybody recognizes.
• Validation here checks the syntax, the version, and the RFC variant bits.
• Batch export is the boring-but-useful one: seeding tests, fixtures, migration scripts, throwaway API examples.

A few things storage actually cares about

Be consistent. If your database ships a native UUID type, use it instead of cramming the thing into a plain string, you'll thank yourself later. Pick one casing and stick to it across APIs and logs. On really big tables, measure how the index behaves before you go swapping primary keys around, because random keys can quietly wreck write performance. And if what you genuinely need is a secret (password resets, invite links, bearer tokens), generate a proper high-entropy random token and store it with an expiry. A UUID was never built for that.

Frequently asked questions

Can two UUIDs collide?

Technically yes. Realistically, with decent randomness, v4 collisions just are not a thing you will lose sleep over. What does bite people is the boring stuff: a bug, a weak random source, an import that ran twice. That is where your duplicates actually come from.

Is UUID v7 better than UUID v4?

Depends what you are doing, honestly. v7 shines for ordered inserts and log data. v4 is still the easy, works everywhere default. I lean v7 lately, but I might be talking myself into a trend.

Can I use a UUID as a secret token?

No. It is a name for something, full stop. Your app rules decide who is authorized, and real secret tokens get generated and stored as secrets, not borrowed from an ID field.

What is the difference between UUID v4 and v7?

v4 is random the whole way through. v7 puts a timestamp up front and randomness behind it, so it lines up chronologically and tends to play much nicer with database indexes.

Should I use a UUID as a database primary key?

You can. It just costs you. Random v4 keys scatter your index and drag down write performance once the table gets big. Reach for v7 instead, or keep a normal sequential primary key and park the UUID in its own column.