UUID Generator
Generate UUID v1, v4, v7 — bulk and validated.
How to use UUID Generator
- Switch to the Generate tab and pick a version (v1, v4, or v7).
- Enter the number of UUIDs you need (1 to 10,000).
- Click Generate — press ⌘/Ctrl + Enter to repeat without reaching for the mouse.
- Use Copy all to grab the full list, or Share to persist your version + count choice in the URL.
- Switch to the Validate tab, paste any UUID, and the tool reports its version, RFC variant, and (for v7) the embedded timestamp.
- Paste a raw UUID without hyphens or with a `urn:uuid:` prefix? The validator rejects it with a clear message so you know to normalise first.
UUID Generator
A RFC 9562-compliant UUID generator that mints v1 (time-based), v4 (random), and v7 (time-ordered) identifiers in bulk, directly in your browser. Every byte of entropy comes from crypto.getRandomValues, every version and variant bit is set exactly where the spec demands, and nothing ever leaves the page — no API, no analytics, no logging.
Why a dedicated UUID tool
Most online UUID generators fall into one of three traps: they ship a 1990s v4-only implementation that predates v7 entirely, they reach for a library that inflates bundle size just to produce 16 random bytes, or they silently POST your generated values back to a server that logs every batch. Developers building modern systems need the opposite: a client-side mint that supports v7 for database-primary-key workloads, supports v1 for legacy interoperability, supports v4 for the classic random case, and validates untrusted input with explicit version and variant detection.
The UUID Generator on dev101.io is that tool. The entire transform is ~200 lines of TypeScript with zero runtime dependencies — the whole thing boils down to crypto.getRandomValues plus bit manipulation. That means it works offline once the page is cached, it works inside corporate network boundaries that block outbound API calls, and it works on the CI job that needs a handful of fresh ids for a fixture without shelling out to uuidgen.
What it does
- UUID v4 (random). 122 random bits with the version nibble set to
0x4and the RFC variant bits set to10xx. The default choice when you do not care about ordering. - UUID v7 (time-ordered). A 48-bit unix-millisecond timestamp in the leading bits followed by 74 random bits. Strings sort lexicographically by mint time, which is the property modern databases want on primary keys.
- UUID v1 (gregorian time + node). 60-bit 100-ns-since-1582 timestamp, 14-bit clock sequence, and a 48-bit random node id with the multicast bit set so the UUID never leaks your real MAC address.
- Bulk generation up to 10,000 per click. Count is clamped client-side and the generator runs in a tight loop — a thousand v4 ids mint in well under a millisecond on a laptop.
- Validation with version and variant detection. Paste any canonical 8-4-4-4-12 UUID and the validator reports the version nibble, the RFC variant class (rfc, ncs, microsoft, future), and — when the input is v7 — the embedded millisecond timestamp converted to ISO 8601.
- Hash-state share URLs. Your version + count preferences round-trip through the URL fragment so you can bookmark "give me 200 v7 ids" as a one-click link.
- Copy all, keyboard-first workflow. ⌘/Ctrl + Enter generates; the copy button hits the clipboard API; nothing blocks the main thread for long enough to notice.
UUID v4 vs UUID v7 — which to pick
UUID v4 is the right default for most non-database use cases: session ids, request ids on a service boundary, cache keys, ephemeral tokens. Its pure randomness is a feature — there is no information leakage about when or where the id was minted. The downside only materialises when the id becomes a primary key on a write-heavy table: the random leading bits mean every insert lands in a random leaf of the B-tree, fragmenting the index and inflating write amplification.
UUID v7 is the answer if the id will be persisted as a primary key, an event id, or anywhere a "created-at" ordering would otherwise be attached in a separate column. Because the leading 48 bits are a monotonic millisecond timestamp, inserts land at the right edge of the B-tree, matching the cache behaviour of an auto-increment integer while retaining global uniqueness. The tail-end 74 random bits mean a v7 UUID is still trillions-of-years safe against accidental collisions.
UUID v1 is rarely the right choice for a new system but still ships because some legacy protocols and interop scenarios mandate it. The gregorian-epoch timestamp structure is unfamiliar to most modern tooling, and the original v1 spec embedded a real MAC address — a privacy disaster. This tool always uses a random node id with the multicast bit set so no hardware identity leaks.
Privacy and trust
Every operation — generation, validation, timestamp extraction, copy to clipboard — runs in your browser. There is no server endpoint invoked when you click Generate. There is no analytics script observing which UUIDs you produce. There are no third-party scripts wedged between your clipboard and the output. The source is available in the repository, the bundle has zero new dependencies, and the implementation is ~200 lines that you can read end to end in a single sitting. If you are minting UUIDs for a session cookie, a tenant id, or an identifier that must not leak to a logging service, this tool is the safe default.
Related tools
- SHA-256 Hash — when you need a deterministic id derived from content rather than entropy.
- Base64 Encode / Decode — commonly paired with UUIDs when packing ids into URLs or authorization headers.
- Hex Encoder / Decoder — inspect the raw bytes behind a UUID or build a custom id format.
Frequently asked questions
What is the difference between UUID v4 and UUID v7?
UUID v4 is 122 random bits with a fixed version and variant stamp — every id is effectively independent and the ordering is pure entropy. UUID v7 embeds a 48-bit unix-millisecond timestamp in the leading bits, followed by 74 random bits, so the string sorts lexicographically by creation time. v4 is the right default when you don't care about time ordering; v7 is the modern database-primary-key choice because its physical insertion order on a B-tree matches generation order, avoiding the random-write amplification that v4 causes on tables with millions of rows.
What is the collision probability for UUID v4?
A UUID v4 carries 122 bits of randomness, which gives roughly 5.3 × 10³⁶ possible values. Using the birthday bound, you would need to generate about 2.71 × 10¹⁸ UUIDs before a 50% chance of one collision emerges — that is trillions per second for thousands of years. For any realistic application the collision probability is indistinguishable from zero, provided the underlying random number generator is cryptographically strong. This tool uses `crypto.getRandomValues`, which is a CSPRNG on every browser and Node.js runtime.
Should I use a UUID as a primary key in my database?
It depends on the version. A v4 UUID as a primary key on a clustered-index storage engine like InnoDB or SQL Server causes random-write fragmentation and page splits because each insert lands in a random leaf of the B-tree, which destroys cache locality and slows down high-volume writes. UUID v7 fixes this by sorting in creation order — inserts append to the right edge of the index, matching the performance profile of an auto-increment integer while keeping the privacy and federation benefits of UUIDs. If your database is Postgres, use `uuid` column type with v7; if it is MySQL, prefer v7 over v4 for any table that writes more than a few hundred rows per second.
Why are UUID v7 ids sortable and what does that actually buy me?
A v7 UUID places a 48-bit big-endian millisecond timestamp in its first 12 hex characters, so a plain string sort or a numeric sort on the id itself produces chronological order. Concretely that means you can paginate by id without a separate `created_at` column, you can range-query a time window with a single `WHERE id BETWEEN` clause, and your database's B-tree stays compact on write. You also keep every property that made UUIDs attractive in the first place — global uniqueness, no central id service, safe to mint on the client — plus a natural audit trail baked into the key.
Are the generated UUIDs unique and safe to use in production?
Yes. Every UUID is produced from `crypto.getRandomValues`, a CSPRNG-backed source of randomness that every modern browser provides. The v4 and v7 generators set the version and variant bits exactly as RFC 9562 specifies, so downstream parsers, database types, and client libraries all recognise the output. The v1 generator uses a random 48-bit node id with the multicast bit set instead of reading your real MAC address, so the UUID does not leak your hardware identity.
Does this UUID generator send my data anywhere?
No. Generation, validation, and timestamp extraction all run locally in your browser tab. There is no API endpoint involved, no analytics on the values you mint, and no outbound request when you click Generate. The Share button encodes your version and count preferences into the URL fragment (#…), which browsers never send to servers by design, so even a shared link keeps everything client-side.