Create a UUID identifier in seconds with XConvert’s UUID generator—fast to use in any modern browser and easy to copy for apps, APIs, and databases.
crypto.getRandomValues() call, so generation takes microseconds even at the upper limit.8-4-4-4-12 positions; copy the value into a regex-strict field exactly as shown.A UUID (Universally Unique Identifier) is a 128-bit value standardized by RFC 9562 (May 2024), which obsoletes the older RFC 4122. The format — 32 hex digits in the layout xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx, where M is the version and the top bits of N are the variant — is the same identifier Microsoft calls a GUID. The point of UUIDs is to let any node in a distributed system mint an identifier on its own, with no central authority, and have effectively zero risk of a collision.
uuid type; MySQL and SQL Server store them as BINARY(16). UUIDs let app servers assign IDs before the row hits the database, which simplifies write-ahead queueing, sharding, and offline-first sync. Pair with v7 when index locality matters.X-Request-ID or traceparent header. OpenTelemetry, Datadog APM, and AWS X-Ray all key spans on these IDs to stitch a multi-service trace together.crypto.getRandomValues()) meet that bar. For higher-entropy or longer tokens, see the password generator.<uuid>/<filename>) spreads writes across S3 partitions automatically.| Version | Bits inside | Sortable? | Reveals metadata? | Use when |
|---|---|---|---|---|
| v1 | 60-bit timestamp + 14-bit clock seq + 48-bit node (MAC) | By time, with caveats | Yes — MAC address leaks the host | Legacy systems that already use it; otherwise skip |
| v3 | MD5(namespace + name) | No | Deterministic — same input always yields same UUID | Reproducible IDs from canonical strings (DNS names, URLs) |
| v4 | 122 random bits | No | None | Default for tokens, request IDs, anything where ordering doesn't matter |
| v5 | SHA-1(namespace + name) | No | Deterministic | Like v3 but with SHA-1; preferred over v3 for new work |
| v6 | Reordered v1 timestamp | Yes (time) | MAC leak unless replaced with random node | Drop-in upgrade path from v1 with index locality |
| v7 | 48-bit Unix-ms timestamp + 74 random bits | Yes (lexicographic) | Creation time only | Database PKs, event keys, anything ordered by insert time |
| v8 | Custom (vendor-defined) | Depends | Depends | Experimental / proprietary schemes |
| NIL | All zeroes | n/a | n/a | Sentinel "no value" |
| Max | All ones | n/a | n/a | Sentinel "end of list" / open upper bound |
| If you care about... | Pick v4 | Pick v7 |
|---|---|---|
| Database index performance | OK for low write rates | Better — appends to B-tree tail |
| Hiding creation time | Yes — 122 random bits | No — timestamp is recoverable |
| Sortable IDs for pagination / event order | No | Yes — lexicographic ≈ chronological |
| Public-facing API tokens | Yes — no leakage | Avoid if creation time is sensitive |
| Migrating from auto-increment integers | Works; expect index bloat | Works with much less bloat |
| Multi-region writes with no clock sync | Yes | Tolerable if clocks within seconds |
v4 is 122 bits of pure randomness — no embedded structure, no order, no metadata. v7 (introduced in RFC 9562, May 2024) places a 48-bit Unix-millisecond timestamp in the high bits and fills the remaining 74 bits with randomness. Two v7 UUIDs created on the same node a millisecond apart will sort in creation order; two v4s next to each other have no relationship. v7's main practical benefit is that inserting it into a B-tree primary-key index appends near the tail instead of scattering across the tree, which dramatically reduces index fragmentation and write amplification on high-insert tables.
Yes for v4 and v7. The generator uses the browser's Web Crypto API crypto.getRandomValues(), which MDN describes as producing "cryptographically strong random values" and which user agents typically seed from a platform random source such as /dev/urandom on Linux/macOS or BCryptGenRandom on Windows. That's the same class of primitive Node's crypto.randomUUID(), Python's secrets, and Go's crypto/rand rely on. v1, v3, v5, and v6 are not random by design — v1/v6 are time-based and v3/v5 are deterministic hashes — so do not use those for session IDs or security tokens.
The 122 random bits give roughly 5.3 × 10^36 possible values. By the birthday-bound approximation, you'd have to generate about 2.71 × 10^18 (2.71 quintillion) UUIDs before reaching a 50% chance of a single collision. At one million v4s per second, that's roughly 86,000 years to a coin-flip's worth of risk. Treat collisions as a physical-impossibility-class event, not a probability you need to handle in code.
Random v4 inserts land at random positions in a B-tree index, causing page splits, cache misses, and write amplification. Real-world Postgres benchmarks at 100M rows show v7 delivering 2–5x better INSERT throughput than v4 with 60–80% less index bloat, because each new v7 is greater than the previous one and inserts append at the tail like an auto-increment integer. The tradeoff: v7 reveals creation time. If your IDs are public-facing and exposing "this row was created at 14:02:07.418" violates a privacy contract, stick with v4.
Yes — this tool runs entirely client-side. After the page loads, you can disconnect your network and keep generating. The Web Crypto API is available in all modern browsers (Chrome, Firefox, Edge, Safari 11+), and crypto.randomUUID() — the native one-line v4 generator — is available in Chrome 92+, Firefox 95+, and Safari 15.4+ as of the W3C Web Crypto API spec. We never send your UUIDs anywhere, which is essential when the UUIDs are session tokens or reset links.
Yes, with one stylistic exception. UUID is the term used in IETF RFCs and most ecosystems; GUID is the term Microsoft has used since COM (.NET, SQL Server, Windows registry). The 128-bit layout is identical and they're interchangeable on the wire. The historical difference is that Windows tools sometimes wrap GUIDs in curly braces ({550e8400-e29b-41d4-a716-446655440000}) and prefer uppercase hex, while RFC 9562 recommends lowercase and bare hyphens. Both forms parse fine in either ecosystem.
RFC 9562 was published in May 2024 and formally obsoletes RFC 4122. The big additions are standardizing v6 (reordered time-based), v7 (Unix-ms time + random — the most important new version), and v8 (custom/vendor). It also clarifies the formal definition of the Nil UUID and adds the Max UUID (all-ones) sentinel. Existing v1, v3, v4, and v5 implementations remain compatible — RFC 9562 is additive, not breaking.
v1 embeds the generating host's 48-bit MAC address in the node field. That's a fingerprint that leaks into anything you persist the UUID into — log files, public APIs, leaked databases. The famous 1999 takedown of the Melissa virus author traced him via a v1 GUID embedded in a Word document. Modern v1 implementations often substitute a random node ID to mitigate this, but v6 and v7 are better-designed replacements and v4 is safer when you don't need time-ordering.
Yes — UUIDs are filename-safe and URL-safe by construction (only 0-9, a-f, and -). They sidestep collision-checking when saving uploads, generated PDFs, or temporary export files. If you want a shorter URL-friendly ID at the cost of UUID compatibility, nanoid trims the default length from 36 to 21 characters with a larger alphabet, but the output is not interchangeable with UUID parsers. Pair UUID filenames with a JSON formatter when emitting manifest files, or use the hash generator when you need a content-addressed name instead of a random one.