Every system that stores things needs identifiers, and the default choice is wrong more often than people expect. Auto-incrementing integers are excellent until the day you merge two databases, restore a backup into production, or accept writes from a second region, and then the sequence has already handed out the same numbers twice. Letting clients invent identifiers solves that and creates a different problem, because an identifier the client controls is an identifier an attacker controls. Random identifiers are the usual answer, and UUID is the most widely deployed form, but the acronym covers at least four meaningfully different things. Version 4 is random. Version 7 is time-ordered with randomness inside it. Version 1 embeds a timestamp and a hardware address. Version 5 is derived from a name, so it is the same value every time. They share a shape and interoperate identically, and choosing the wrong one costs you index performance or quietly leaks information about your infrastructure. This page generates version 4, which is right for the large majority of uses.
v4, v7 and the rest - and which one to pick
The current specification is RFC 9562, published in 2024, which replaced the older RFC 4122. All versions are 128 bits written as 32 hexadecimal digits and four hyphens, with certain bits fixed to identify the version and the variant, leaving 122 usable bits. Version 4 fills all 122 with random data. Version 7, added in the new specification, puts a 48-bit big-endian millisecond timestamp in the front and random bits behind it, so values sort in creation order. That single difference matters for databases: random keys land anywhere in a B-tree index, causing page splits and poor cache locality on every insert, while time-ordered keys append. Version 1 is the old time-based scheme and embeds the network hardware address, which is a privacy leak that also made it famous as the MAC address of a machine you own. Versions 3 and 5 hash a name inside a namespace, with SHA-1 and SHA-256 respectively, so the same name always produces the same value - useful for idempotency keys, useless if you want uniqueness by chance. Default to v4; consider v7 for a write-heavy table.
What the collision arithmetic actually says
A version 4 UUID has about 5.3 times 10 to the 36 possible values, which is why the collision estimates people quote are so small. Using the birthday calculation, generating a billion random v4 values gives a probability of any collision on the order of 10 to the minus 19 - effectively never. You would need on the order of ten billion identifiers before the 50 percent mark becomes conceivable. The same reasoning shows why randomness at a smaller width does not work: a 32-bit random identifier collides with useful probability after about 65,000 values, because collisions in a large space arrive far earlier than intuition suggests. Two practical notes. Some runtimes, including .NET, carry the same 122 bits in a different layout, so a value printed there and a value printed here have the same guarantees but different text. And if a system stores only part of the string, or truncates it for display, entropy really is lost - treat a shortened UUID as a different, weaker identifier.
Where UUIDs cost you something
Storage and indexes are the usual complaints, and they are legitimate. A 36-character text key is far larger than an 8-byte integer, and random insertion order fragments the index. Most databases have a native UUID type that stores 16 bytes, so using it instead of a text column is often the single biggest win available. Logs are the second: 36 random characters per line make human reading painful and push log aggregation systems into high-cardinality problems, so keep a real created_at column and do not try to derive a timestamp from a v4 value - it is not there. The third is security. A v4 value generated with a cryptographic random source is not guessable, but a v1 value advertises when and where it was created, and a UUID that appears in a URL ends up in logs and referrer headers. If a UUID is your only authentication secret, ask yourself whether it also appears in a log line somewhere.
Frequently asked questions
Are these UUIDs really random?
Yes, version 4 values are filled from the browser's cryptographic random source, which is the same generator your platform uses for key material. They are not produced by a math random function, so they are not predictable from previous values, and the order in which they appear on the page carries no information about the values themselves.
Should I use v4 or v7?
Use v4 unless your table takes a very high rate of inserts. Version 7 puts a timestamp in front, so new rows land at the end of the index instead of scattering across it, which is a large difference in write performance on a busy table. Both are equally safe to guess, and v7 is now part of the main UUID specification.
Can I use a UUID as a session token or API key?
A v4 value is generated from a strong random source, so it is not guessable, and it is a reasonable identifier for a link or a job. Be aware of where it travels: anything in a URL ends up in server logs, browser history and referrer headers, so a UUID that is also a secret is a UUID that can leak. Version 1 is a poor choice for anything sensitive, because it encodes a timestamp and a hardware address.
Does this page send anything anywhere?
No. Generation happens in your browser tab, there is no upload endpoint, and the values disappear when you close the tab. The site is funded by advertising, so ad providers can see page-level information such as your IP address and the pages you visit, but not the identifiers you generate.