Generate UUIDs of any version. Random (v4), time-ordered (v7, RFC 9562), legacy timestamp (v1), or NIL. Bulk generation, formatting options, instant copy. Everything runs in your browser.
| Version | Spec | Use when |
|---|---|---|
| v4 | RFC 4122 (2005) | Default choice. Pure randomness, 122 bits of entropy. |
| v7 | RFC 9562 (2024) | Database primary keys. Sorts by creation time, avoids B-tree fragmentation. |
| v1 | RFC 4122 (2005) | Legacy systems that need MAC+timestamp encoding. |
| NIL | RFC 4122 §4.1.7 | Sentinel "no UUID yet" value. All zeros. |
Which UUID version should I use?
Use v4 for general randomness. Use v7 for database primary keys (sorts by time, kinder to B-trees). Use v1 for legacy compatibility, NIL as a sentinel value.
Is UUID v4 truly random?
Effectively yes — 122 bits from crypto.getRandomValues. Collision probability is
negligible at any realistic scale.
Why does v7 help my database?
v7 puts a millisecond timestamp in the high bits, so newly generated values insert at the end of B-tree indexes instead of randomly. That means fewer page splits, less fragmentation, and faster inserts at high throughput.
Are UUIDs case-sensitive?
No — by spec they're case-insensitive. Most outputs are lowercase (RFC recommendation), but some Windows APIs return uppercase. Compare by lowercasing first.
Is anything sent to a server?
No. Pure client-side crypto.getRandomValues.