UUID Generator
Generate batches of cryptographically secure UUID v4; optional uppercase and hyphen stripping, one click for another batch.
>_ USAGE GUIDE
The version selector supports v4 / v7 / v5: v4 is pure random (the default and the most common); v7 is the new time-ordered standard (RFC 9562) with a 48-bit millisecond timestamp in its leading bits — batches come out strictly monotonic, which databases love; v5 derives deterministically from a namespace and a name, so the same inputs always produce the same UUID — ideal for assigning stable IDs to fixed entities.
- Pick the version: v4 for random IDs, v7 for time-sortable primary keys, v5 for deterministic name-based IDs
- Fill v5 inputs when needed: choose one of the four RFC-preset namespaces (DNS / URL / OID / X.500) and type a name such as
example.com - Batch and format: for v4/v7, choose the count; uppercase and hyphen-stripping options apply to all versions
- Copy or regenerate: results list one per line, copyable as a whole batch
Every ID is drawn from the browser's cryptographically secure random source. Generation runs entirely locally with zero network requests, so the results are production-usable the moment they appear.
>_ FAQ
Q1 · Is there a difference between UUID and GUID?
No substantive one — GUID is simply Microsoft's name for a UUID, and both refer to the same universal unique identifier. The terms are interchangeable in everyday use; only specific Microsoft ecosystems (COM registry formats, for instance) attach particular formatting conventions to GUID.
Q2 · UUIDv7 vs v4 — which should I use?
v4 is 122 bits of pure randomness with no pattern at all; v7 puts a millisecond timestamp in the leading 48 bits, so later-generated IDs sort higher — batches are strictly monotonic. As a database primary key, v7 inserts cluster in time order, causing fewer page splits and faster writes, and supports time-range scans naturally. v4 scatters randomly across the index (B-tree unfriendly) but leaks no timing information. New projects doing primary keys should prefer v7; externally exposed anti-enumeration scenarios (order numbers, file IDs) are better served by v4.
Q3 · What is v5 and when do I use it?
v5 = a deterministic SHA-1(namespace ∥ name) derivation: with the same namespace (say DNS) and the same name (say example.com), anyone on any machine gets the identical UUID. It is meant for mapping things that already have stable identifiers onto UUIDs — a permanent key for a domain, URL or OID. Keep in mind it is deterministic by design: it offers no uniqueness guarantee (same inputs always collide by definition), which is exactly what separates it from v4/v7.
Q4 · Can generated UUIDs collide?
For v4, theoretically yes (2^122 combinations), practically never — the probability of a billion generated UUIDs all colliding is lower than winning the lottery several times over. That is what lets distributed systems generate IDs without coordination. For v7, an incrementing counter keeps same-millisecond batches strictly non-repeating, and the timestamp advances across milliseconds. Systems with strict uniqueness audits should still back this with a unique index.
Q5 · Why does a UUID look like "8-4-4-4-12"?
That is the standard textual form defined by RFC 9562 (formerly RFC 4122): 32 hexadecimal characters grouped at fixed positions. The first character of the third group encodes the version (v4 is 4, v5 is 5, v7 is 7), and the first character of the fourth group encodes the variant — checking those two characters is the quickest way to tell which version a UUID is.