Are these UUIDs truly random?
Yes. They come from crypto.getRandomValues, the browser's cryptographically secure random number generator. Nothing is generated on a server.
Generated in your browser.
Generate up to 1,000 identifiers at once with the browser's cryptographic random number generator, then paste any ID back in to see its version and the time it was made.
Loading the toolbox.
You do not have to take our word that your data stays here. Developer tools show every request a page makes, so you can watch this page work and confirm that nothing is sent. The check takes under a minute.
F12, or Cmd+Option+I on a Mac, and select the Network tab.Only two things can add a line to that log, and neither carries your data. Submitting the feedback form sends the vote and comment you typed. Typing characters in a script the page has not displayed yet, such as Cyrillic or Greek, can make the browser fetch the matching font file, and that request names only the font.
The production site also sends a Content-Security-Policy header that tells your browser to refuse connections to anywhere except this site and the anonymous analytics endpoint, so a coding mistake could not quietly send your data elsewhere.
A UUID, or universally unique identifier, is a 128-bit value written as 32 hexadecimal digits in five groups, such as 0190f3c2-7a4e-7b3d-9a1c-3f2e4d5c6b7a. The digit after the second dash is the version, and the first digit of the fourth group encodes the variant. RFC 9562, published in 2024, is the current standard and defines versions 1 through 8.
Any system can create a UUID without asking a central server, and the chance of two random ones colliding is so small that it can be ignored in practice. That is why they are the default primary key in many databases and the standard way to name events, files, and requests.
Version 4 is 122 random bits. It reveals nothing about when or where it was made, which is ideal for public tokens. Its randomness is also its weakness as a database key: new rows land at random places in the index, which fragments B-tree pages and slows inserts on large tables.
Version 7 starts with a 48-bit Unix timestamp in milliseconds, followed by random bits. New IDs sort after older ones, so inserts append to the end of the index, and you can read the creation time back out. 2uuid also makes v7 monotonic within a millisecond, so a bulk batch sorts in the exact order it was generated. Use v7 for keys and v4 when the creation time should stay private.
2uuid uses rejection sampling for NanoID, so every character in a custom alphabet is equally likely.
Paste an ID and 2uuid detects its type. For UUID v1 and v6 it reads the 60-bit Gregorian timestamp, the clock sequence, and the node field. For v7 and ULID it reads the millisecond timestamp and shows it in UTC and in your local time. For v4, v3, and v5 it explains why there is no time to read. It also recognizes the nil and max UUIDs and accepts braces and the urn:uuid: prefix.
The vanilla 2uuid this tool replaces truncated timestamps to 32 bits and could not detect v7 at all. Both bugs are fixed and covered by tests.
Elsewhere in the toolbox: 2hash, 2base, 2otp, 2xml, and more on the 2toolbox home page. Part of the 2suite.io privacy-first ecosystem.
Yes. They come from crypto.getRandomValues, the browser's cryptographically secure random number generator. Nothing is generated on a server.
No. Within one millisecond 2uuid increments a 12-bit counter, so every batch sorts in generation order.
It reveals the millisecond it was created. If that matters, for example in a public URL, use v4 instead.
Its randomness matches UUID v4, so collisions are not a practical concern. It is shorter but does not sort by time.