Security & devFreeNo signup
Generate free UUID v4 identifiers in bulk for apps, databases, and testing. Copy-ready browser tool.
Last updated 2 October 2026
An identifier generator, not a secret generator. Every value above is 122 random bits in the layout RFC 9562 defines for version 4. That is enough randomness to make a duplicate implausible and not enough authority to protect anything: RFC 9562 section 8 says a UUID MUST NOT be used as a security capability. Each figure below carries its source and the date it was read.
RFC 9562, Universally Unique IDentifiers (UUIDs), was published in May 2024 and its header says plainly: Obsoletes: 4122. RFC 4122, which it replaced, dates from July 2005 and is still what a great deal of writing about UUIDs cites, including, as it happens, the browser specification this page depends on. For the identifiers in the panel above the two documents agree on the bits, so nothing you copy from here is affected. They disagree about three things that bite in practice, and this page is written against the current one.
The first is that RFC 9562 added versions 6, 7 and 8, and version 7 changes the right answer to the most common question anybody asks about UUIDs. The second is the case of the output, covered further down, where the 2024 document relaxed a rule the 2005 document imposed. The third is a whole section of best practices, sections 6.1 through 6.13, which did not exist before and which is where the useful material now lives.
That last point is checkable rather than rhetorical. The Web Cryptography API specifies crypto.randomUUID(), the function this page calls, as generating “a new version 4 UUID” and returning “its namespace specific string representation as described in section 3 of [RFC4122]”. Read on 2 October 2026, the standard behind the browser function still points at the obsoleted RFC. It does not matter for correctness, because section 3 of RFC 4122 and section 4 of RFC 9562 describe the same string.
A UUID is “16 octets (128 bits) in size”, and six of those bits are not yours. RFC 9562 section 4.2 puts the version in “the most significant 4 bits of octet 6”, and section 4.1 requires that “bits 64 and 65 of the UUID (bits 0 and 1 of octet 8) MUST be set to 1 and 0”. Version 4 therefore has, in the words of section 5.4, “122 bits total” of random data, split across three fields the specification names random_a, random_b and random_c.
Those six fixed bits are visible in every line of output above, in exactly two places, and you can check the claim against the panel without trusting this paragraph.
Where to look in a version 4 UUID · positions counted in the dashed text form
Twenty thousand identifiers were generated from this page's own code while writing this section. The version nibble was 4 in all twenty thousand. The variant nibble was 8 in 5,004 of them, 9 in 5,018, a in 5,025 and b in 4,953, which is the even quarter-split you would expect from two random bits, and none of the twenty thousand departed from the dashed 8-4-4-4-12 shape RFC 9562 gives in ABNF. That is not a proof of randomness, and no amount of sampling would be. It is a check that the version and variant bits are where the specification puts them, which is the part a wrong implementation gets wrong.
The fixed bits have a cost worth naming, because pages that advertise “2128 possible values” are overstating it by a factor of 64. A 128-bit space holds 340,282,366,920,938,463,463,374,607,431,768,211,456 values. The version 4 space holds 5,316,911,983,139,663,491,615,228,241,121,378,304. The second number is the first divided by 26.
The figure usually given is that you need about 103 trillion version 4 UUIDs before there is a one in a billion chance that two of them match. It is generally quoted without its working, which makes it impossible to check or to adapt to a different probability. It is also right, and it follows from the one sourced input above.
The birthday bound says the number of draws n needed to reach a collision probability p in a space of N values is roughly the square root of 2Np. With N = 2122 from RFC 9562 section 5.4, the arithmetic gives the table below. It was carried out in exact decimal for this page rather than copied.
Chance that any two of n version 4 UUIDs collide · computed from the 122 random bits in RFC 9562 section 5.4
At the 200 per click this page allows, the one in a billion row is 515 billion clicks. At a million identifiers a second it is about 3.3 years of continuous generation. For any ordinary application the answer to “are they unique enough” is yes, and the reason is a number rather than a reassurance.
RFC 9562 is nonetheless careful not to promise what cannot be promised. Section 6.8: “Although true global uniqueness is impossible to guarantee without a shared knowledge scheme, a shared knowledge scheme is not required by a UUID to provide uniqueness for practical implementation purposes.” Section 6.7 then asks you to decide what a collision would cost, and gives two scenarios rather than a rule. Low impact: “a UUID collision generated a duplicate log entry, which results in incorrect statistics derived from the data.” High impact: “a duplicate key causes an airplane to receive the wrong course, which puts people's lives at risk. In this scenario, there is no margin for error.” The specification's position is that the probability is a fact and the acceptability is your judgement.
The generator above tries crypto.randomUUID() first and falls back to filling sixteen bytes from crypto.getRandomValues() and setting the version and variant bits by hand. That looks like a compromise, as though the fallback were a cheaper substitute. It is not. The Web Cryptography API defines randomUUID() as this procedure, in these steps: let bytes be a byte sequence of length 16; “fill bytes with cryptographically secure random bytes”; “set the 4 most significant bits of bytes[6], which represent the UUID version, to 0100”; “set the 2 most significant bits of bytes[8], which represent the UUID variant, to 10”; then concatenate the hexadecimal representations with hyphens. The fallback on this page is the same five steps written out.
What differs is availability, and the reason is a rule about the page's own origin rather than anything about randomness. In the Web Cryptography API's interface definition, randomUUID() is annotated [SecureContext] and getRandomValues() is not. Under the Secure Contexts specification an origin is potentially trustworthy if “origin's scheme is either ‘https’ or ‘wss’”, or if “origin's host matches one of the CIDR notations 127.0.0.0/8 or ::1/128”, or if the host is localhost or ends in .localhost. A page served over plain http from a hostname on a private network satisfies none of those, so randomUUID() is absent there and getRandomValues() is still present. That is the whole reason for the second path.
On the quality of the bytes themselves, the Web Cryptography API's note is a should rather than a guarantee: “Implementations should generate cryptographically strong random values using well-established cryptographic pseudo-random number generators seeded with high-quality entropy, such as from an operating-system entropy source (e.g., ‘/dev/urandom’)”, and it adds that the specification “provides no lower-bound on the information theoretic entropy present in cryptographically strong random values”. RFC 9562 section 6.9 asks for the same thing from the same direction: implementations “SHOULD utilize a cryptographically secure pseudorandom number generator (CSPRNG)”, with the only exception being “when a suitable CSPRNG is unavailable in the execution environment”. Both documents are describing an intent that browsers meet, not a property either one can enforce.
This is the paragraph on the page that has cost people money. RFC 9562 section 8, in full on this point:
RFC 9562, section 8, Security Considerations
The pattern that rule forbids is extremely common: an upload, a document, a report or an invitation is put at a URL containing a UUID and shared as though the URL were a password, with no check on the server beyond “does this identifier exist”. 122 random bits is genuinely a lot, so the objection is not that somebody will guess one. It is that a URL is not a secret in the way a password is. It appears in browser history, in the referrer sent to the next site, in server and proxy logs, in link previews generated by chat applications and mail clients, in screenshots and in copy-paste. The specification's own framing is the useful one: do not assume unguessability, because “discovery of predictability in a random number source will result in a vulnerability”, and your code has no way to notice that day.
There is a nuance in the same section that reads like a contradiction and is not. Section 8 also says that “if UUIDs are required for use with any security operation within an application context in any shape or form, then UUIDv4 SHOULD be utilized.” It is ranking the versions, not endorsing the practice: among UUID versions, the one with no embedded clock and no hardware identity is the only defensible choice near a security decision. The first rule still stands over the top of it.
The description this page shipped for years said a UUID is “commonly used for database rows, jobs, and API resources”, and that is true. It is also the case where RFC 9562 most clearly points somewhere other than version 4.
Section 6.11: “Time-ordered monotonic UUIDs benefit from greater database-index locality because the new values are near each other in the index. As a result, objects are more easily clustered together for better performance. The real-world differences in this approach of index locality versus random data inserts can be one order of magnitude or more.” Random version 4 values are the “random data inserts” that comparison is made against. Every insert lands at an unpredictable point in the index, so a B-tree is dirtied across its whole width instead of at its right-hand edge.
Version 7 is RFC 9562's answer. Section 5.7 puts “a Unix timestamp in milliseconds in the most significant 48 bits” and fills “the remaining 74 bits, excluding the required version and variant bits, with random bits”, which makes the values sort by creation time as opaque bytes and as text, while keeping 74 bits of randomness inside each millisecond. The specification's recommendation is explicit: “Implementations SHOULD utilize UUIDv7 instead of UUIDv1 and UUIDv6 if possible.”
Two more pieces of section 6.13 are worth carrying away, because they cost storage rather than performance. UUIDs “SHOULD be stored within database applications as the underlying 128-bit binary value”, since “storing UUIDs as text is unnecessarily verbose, requiring 288 bits to represent 128-bit UUID values”. And schema designers are “cautioned against using name-based UUIDs … as primary keys in tables”, because they are derived from a value somebody assumed would never change.
This page makes version 4 and only version 4. If what you need is a sortable key, the generator above is the wrong tool and no option on it will fix that. Your database or your language runtime is where to get a version 7.
Here the two specifications genuinely disagree, and the disagreement is a real source of bugs. RFC 4122 section 3, 2005: “The hexadecimal values ‘a’ through ‘f’ are output as lower case characters and are case insensitive on input.” RFC 9562 section 4, 2024, after giving the ABNF: “Note that the alphabetic characters may be all uppercase, all lowercase, or mixed case.” A generator written against the current specification may hand you F81D4FAE-7DEC-11D0-A765-00A0C91E6BF6 and be conforming.
The output above is lower case, because that is what the Web Cryptography API requires of itself: the hexadecimal representation of a byte is “the two-character string created by expressing value in hexadecimal using ASCII lower hex digits, left-padded with ‘0’ to reach two ASCII lower hex digits”. So the browser method is stricter than the RFC it implements. Other producers are not obliged to be, and RFC 9562 section 4 notes that some implementations, naming Python and Microsoft, “will output UUID with the string format, including dashes, enclosed in curly braces”.
Four renderings of one identifier, all of them the same 128 bits
That example is RFC 9562's own, from Figures 1, 3 and 4 of section 4, where it is also given as a URN: urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6. The consequence for code is simple and frequently missed. Any UUID compared as a string, used as a cache key, or made unique by a text index can be defeated by case or by braces. Normalise before comparing, or store the 128 bits and let the database compare bytes. RFC 9562 section 6.12 pushes the same way from a different angle: “avoiding parsing UUID values unnecessarily is recommended; instead, treat UUIDs as opaquely as possible.”
The panel has one input, a count. Everything below is outside what a count and a random number generator can tell you.
Whether a duplicate would matter. The arithmetic above gives a probability. RFC 9562 section 6.7 asks for the consequence, and only you have that: a duplicate log line and a duplicate key on a safety-critical record sit at opposite ends of the same table.
Whether your system wants version 4 at all. For an API resource or a job identifier it is a good fit. For a high-insert primary key, section 6.11's “one order of magnitude or more” is pointing elsewhere, and this page cannot make a version 7.
How your database will store it. 128 bits as binary or 288 bits as text is a schema decision made somewhere other than here, and section 6.13 has a preference.
What the browser's entropy source actually is. Both the Web Cryptography API and RFC 9562 section 6.9 express this as a should. The page can call the function. It cannot inspect the pool behind it, and on a plain http origin it cannot call randomUUID() at all.
Whether you are about to use one as a password. Section 8 forbids it and the page cannot stop you.
What you typed. The count is clamped to 1 through 200 with no message: 1000 silently becomes 200, and 0, a negative number or a word silently becomes 1. If you asked for more than 200 and got 200, nothing on the page said so.
Nothing you type above leaves your browser, and the identifiers are generated on your own machine. Because they are generated locally and never recorded, this page also cannot tell you whether a value it produced has been produced before.
Every quotation above was read from the document named on 2 October 2026, from the IETF and W3C publications themselves rather than from a summary. The collision table was computed in exact decimal arithmetic from the 122-bit figure in RFC 9562 section 5.4 using the standard birthday approximation, and the version and variant distributions were measured by running this page's own generator function 20,000 times. Part of the QuikUtil tools collection; the Password Generator is the right tool when you need something that is meant to be secret, and the Hash Generator covers the name-based case this page does not.
Version 4 only: the randomly or pseudorandomly generated version in Table 2 of RFC 9562. Every identifier above carries the hexadecimal digit 4 in the thirteenth position and one of 8, 9, a or b in the seventeenth, because RFC 9562 fixes four version bits in octet 6 and two variant bits in octet 8. That leaves 122 of the 128 bits random. If you want the time-ordered version 7 that RFC 9562 introduced, this page cannot make it, and that matters for database keys.
That depends on what a collision would cost you, and the number is computable. With 122 random bits the space holds 5,316,911,983,139,663,491,615,228,241,121,378,304 values, and the birthday bound puts the chance of a single duplicate at about one in a billion after 103.1 trillion identifiers. Generating a million a second you would reach that threshold in roughly 3.3 years. But RFC 9562 is careful: it says true global uniqueness is impossible to guarantee without a shared knowledge scheme, and it asks you to weigh what a collision would actually do. A duplicate log line is a statistics problem. A duplicate primary key on something safety-critical is not.
No, and RFC 9562 says so in the strongest language it uses anywhere. Section 8: “Implementations SHOULD NOT assume that UUIDs are hard to guess. For example, they MUST NOT be used as security capabilities (identifiers whose mere possession grants access).” A share link whose only protection is the UUID in it is exactly the pattern that sentence forbids. Use a token your authorisation layer actually checks.
From the browser. The page calls crypto.randomUUID() where it exists, and otherwise fills sixteen bytes from crypto.getRandomValues() and sets the version and variant bits itself. Those are not two different qualities of randomness: the Web Cryptography API specifies randomUUID() as exactly that procedure, sixteen cryptographically secure random bytes with the four most significant bits of byte 6 set to 0100 and the two most significant bits of byte 8 set to 10. The fallback exists because randomUUID() is marked SecureContext and getRandomValues() is not, so on a plain http preview only one of the two is available.
Probably not, and this page cannot give you the better answer. RFC 9562 section 6.11 says time-ordered monotonic UUIDs “benefit from greater database-index locality because the new values are near each other in the index” and puts the real-world difference at “one order of magnitude or more”. Random version 4 values are the case that difference is measured against. Section 6.13 adds that UUIDs should be stored as the underlying 128-bit binary value where feasible, because the text form needs 288 bits to carry 128 bits of information. Version 7 is what the specification points you at, and your database or your language runtime is the place to get it.
It mattered and then it stopped. RFC 4122, from 2005, required that “the hexadecimal values ‘a’ through ‘f’ are output as lower case characters and are case insensitive on input”. RFC 9562, which obsoleted it in May 2024, instead notes that “the alphabetic characters may be all uppercase, all lowercase, or mixed case”. So a conforming generator may now hand you either, while the Web Cryptography API still requires its own randomUUID() output to use ASCII lower hex digits. If anything in your system compares UUIDs as strings, normalise the case before you compare, or store them as bytes.
Two hundred. The field is clamped to the range 1 to 200, silently: typing 1000 produces 200, and typing 0, a negative number or a word produces 1. Nothing on the page tells you the clamp happened.
Not from a version 4 one, and that is the point of it. Version 1 embedded a timestamp and, traditionally, the machine's IEEE 802 MAC address, which is why RFC 9562 section 8 says MAC addresses “pose inherent security risks around privacy and SHOULD NOT be used within a UUID”. The identifiers above carry no clock and no hardware identity, only 122 random bits. Version 7 reintroduces a timestamp deliberately, as a sortable prefix, and discloses the creation time to anyone holding the value.