🔗 UUID and NanoID Generator
UUID v1, v4, v6, v7 and NanoIDs, generated in your browser. Bulk supported.
Last updated: May 18, 2026 · By Λ
By Λ · Updated May 18, 2026 · ~4 min read
Which UUID version should I actually use in 2026?
The honest answer is: for new databases, use UUID v7. For everything else, v4 is fine. The reason v7 is the right default for new code: it puts a millisecond timestamp in the first 48 bits, so when you insert UUIDs as primary keys in a B-tree index (which Postgres, MySQL, and SQL Server all do by default), inserts cluster at the right edge of the tree instead of scattering. The performance difference on inserts is roughly 3-5x on tables above a few million rows.
v4 is the classic random UUID. Use it when ordering doesn't matter, you do not have a primary-key index issue, or you want maximum unpredictability (URLs containing a session token, for example). v1 and v6 are timestamp-based but include a MAC address in the node field. v1 was the original; v6 is a re-ordered v1 with the timestamp in big-endian byte order so it sorts properly. I include both because tooling that talks to legacy systems sometimes needs them.
Why NanoID?
NanoIDs are URL-safe random strings shorter than UUIDs (21 characters by default versus a UUID's 36) that pack the same amount of entropy. They are the right choice for public IDs you put in URLs: shorter to type, easier to scan, no hyphens to copy-paste-mangle. The default 21-character NanoID has 126 bits of entropy, slightly more than a v4 UUID's 122.
The length-vs-collision-risk math: with a 21-char NanoID, you would need to generate roughly 30 trillion IDs before there is a 1-in-a-billion chance of collision. For most apps, that is "never". If you need longer, the picker lets you go up to 64 characters.
How the generator works
Random bits come from crypto.getRandomValues() and timestamps from Date.now(), both called directly on your machine, so no generated ID ever crosses a network connection. The v7 implementation follows RFC 9562 (released 2024) which formally specifies the new versions.
Bulk generation supports up to 1,000 IDs at a time. For larger volumes (say, importing a million records), generate in chunks or use your database's native UUID function instead, since the overhead of getting the IDs to your insert script eats any gain.
Common mistakes
Storing UUIDs as VARCHAR(36). Use the native UUID type if your database has one (Postgres, MySQL 8+, SQL Server). Storing as text wastes 16 bytes per row and prevents index optimizations.
Treating UUIDs as secrets. v4 is unpredictable but v1/v6/v7 leak the timestamp. If you put a v7 UUID in a public URL, an attacker can tell roughly when the row was created. For session tokens, use v4 or a random NanoID.
Trying to make UUIDs human-readable. You cannot. Use a slug for human-readable identifiers and store the UUID as the database key. The slug generator handles that side.
Frequently Asked Questions
Why do my v7 UUIDs all share the same opening characters?
That is the feature, not a bug. The first 48 bits of a v7 UUID encode the millisecond it was created, so IDs made within the same session begin with a near-identical prefix and sort in creation order.
Does the v1 option expose my MAC address?
No. Instead of reading your real network card, this implementation fills the node field with random bytes and sets the multicast bit, the standard way to signal "this is not a hardware address". You get a spec-shaped v1 without the privacy leak the original design had.
Are NanoIDs from this page safe to use as tokens?
For identifiers, yes. Be aware that the character picker maps random bytes onto the alphabet with a modulo, which gives some characters a marginally higher chance when the alphabet length does not divide 256 evenly. That bias is irrelevant for record IDs; for secrets, prefer a v4 UUID or a dedicated token generator.
What is the {braces} format for?
Windows registry entries, COM, and several Microsoft APIs write GUIDs wrapped in curly braces. The quoted format exists for a similar reason: it drops IDs straight into JSON arrays or SQL IN lists without hand-editing.
Can I generate more than 1,000 IDs in one go?
The count field caps each click at 1,000. Click Generate repeatedly and collect batches with Copy All, or lean on your database's built-in UUID function when seeding millions of rows.