Need an identifier that will not clash with one somebody else made, on a machine you have never heard of, without asking anyone for permission? That is the job a UUID does. It is a 128-bit number, written as 36 characters in the familiar 8-4-4-4-12 pattern, and its whole design is that two of them are not going to be the same even though nothing coordinates who gets which. This free generator makes them in your browser: pick a version in Version, say how many you need in Count, and press Generate. The page opens on a single v4, the version most projects want, so a first identifier is one click away.
Every identifier is built in your browser, and every random part of it comes from the Web Crypto API. Version 4 uses crypto.randomUUID() where the browser provides it and crypto.getRandomValues() otherwise — a cryptographically strong source of randomness rather than a JavaScript pseudo-random function such as Math.random(). Version 7 here puts a 48-bit millisecond timestamp at the front, then a 12-bit counter that steps up within the same millisecond, then 62 random bits — the counter method RFC 9562 describes, one of the layouts it allows; that counter is why a batch of a thousand comes out in order rather than shuffled. Version 1 combines a timestamp with a random node identifier that has the multicast bit set, so it never carries your network card's address the way the original 1990s implementations did. Versions 3 and 5 are not random at all: they hash a namespace together with a name, using MD5 and SHA-1 respectively, and that hashing, done by the page's own MD5 and SHA-1 code rather than by Web Crypto, also happens on your device. Your identifiers are never sent to our server, so we never see or log them, and once the page has loaded it keeps working with the connection off.
Version is the field that decides everything else. Version 4 is 122 random bits and no structure — the default, and the right answer when an identifier only has to be unique. Version 7, as built here, keeps 62 random bits but leads with the time it was created, so a batch of them sorts into the order it was made; that is what makes it the version to reach for when the identifier will become a database key. Version 1 is the original time-based scheme, kept here for systems that still ask for it. Versions 3 and 5 are the odd pair: they are deterministic, meaning the same inputs always produce the same identifier, and they take two extra fields — Namespace, which is one of the standard spaces DNS, URL, OID and X.500 or a Custom one of your own, and Name, the string being identified. Feed v5 the URL namespace and https://example.com/a and you get the same UUID today, tomorrow and on somebody else's machine. Because of that, Count disappears when v3 or v5 is selected: a thousand copies of one deterministic value would be a thousand copies of one deterministic value. For every other version Count runs from 1 to 1000.
Four switches change the shape of the output without changing the 128 bits underneath. Uppercase prints the hexadecimal digits as capitals, Without hyphens gives the compact 32-character form some columns and file names prefer, and Braces wraps the value in curly brackets — the way Windows and .NET usually write a GUID. Under Advanced Options, urn:uuid: adds the prefix that makes it a formal URN; it switches Braces and Without hyphens off while it is on, because the standard allows exactly one URN form and it is the canonical one with hyphens. Copy format decides how a batch is joined when you take it: one per line, separated by commas, or each value in quotes with a trailing comma, which pastes straight into an array in code. Under the result sits a line that reports the randomness in bits — 122 for v4, 62 for v7 — and, for v7, the timestamp encoded in the first identifier of the batch, so the time inside the value is visible rather than implied. Copy All and Save to File both respect Copy format. History keeps your last 10 batches in your own browser: click one to bring it back, copy or delete a single entry, or clear the lot. Clear empties the result and leaves your settings alone, and past 50 identifiers the list becomes one scrollable block instead of fifty rows.
The most consequential thing on this page is the difference between v4 and v7 as a primary key, and it is not a matter of taste. Most database indexes are B-trees kept in sorted order, and where a new key lands in that order decides how much work the insert costs. A v4 key is random, so consecutive inserts land in unrelated corners of the index: pages that were full get split, the parts of the tree the database is holding in memory are rarely the parts the next insert needs, and the index ends up larger and more fragmented than the rows it points at warrant. A v7 key leads with the current millisecond, so consecutive inserts land next to each other at the right-hand edge of the tree, much as an auto-incrementing integer does. How much that gains depends on the database, its indexes and the workload, but that is the trade: v7 brings the insert pattern of a sequential key while keeping the property that made you choose UUIDs in the first place, which is that anyone can mint one without asking a server. What it costs is that the creation time is now readable inside the identifier, and whether that matters is a question about your data, not about the format.
Nothing ever checks a UUID for uniqueness; its size is the guarantee. There is no registry, no server round-trip, no lookup — a generator produces a number and hands it over, and the reason two of them do not collide is simply that there are 2^122 possible v4 values, about 5.3 undecillion. The birthday problem is the honest way to size that: you would need roughly 2.7 quintillion identifiers before there was an even chance of any two of them matching, which is a billion new UUIDs every second for 86 years. It is worth being precise about what that does and does not promise. It is a statistical guarantee, not an arithmetic one, and it holds only while the randomness underneath is real — a generator seeded badly, or a virtual machine cloned along with its entropy pool, breaks it in a way the format cannot detect. Version 7 narrows the question further: within one batch this generator cannot repeat a value at all, because the counter increments rather than rolls dice, and across independent generators the 62 random bits do the work.
A UUID is an identifier, not a password. Version 4 is unpredictable, and that tempts people into treating it as a secret — a password-reset link, an unguessable URL, a session token, an API key. The unpredictability is real, but secrecy is a property of how a value is handled, and identifiers are handled carelessly by design, a point worth noting as context for the CCPA: they sit in URLs, which land in browser history, server logs, referrer headers and analytics, and get pasted into chat messages. The other versions are worse candidates still. Version 1 and version 7 both encode the moment of creation, so anyone holding one knows roughly when it was made and can narrow the neighborhood of everything made alongside it. Versions 3 and 5 are deterministic on purpose: a v5 UUID of an email address is not a hashed secret, it is a value anyone with the same address can compute in a second. Use a UUID to name a thing. Use a password generator, or a token from a library built for secrets, when the value has to stay unknown.
Why choose this UUID generator?
- Browser-only generation: identifiers are made on your device and never sent to our server
- Web Crypto API randomness: cryptographically secure, not Math.random()
- Five versions in one place: v1, v3, v4, v5 and v7, without switching tools
- Genuinely ordered v7: a counter inside the millisecond, as RFC 9562 describes
- Deterministic v3 and v5 with the four standard namespaces or your own
- Up to 1000 at a time, with a compact scrollable list past fifty
- Every common shape: hyphenated, bare, uppercase, braced or a urn:uuid: URN
- Copy as lines, commas or quoted values that paste straight into code
- Unlimited and free: no sign-up, no usage limits, nothing on our servers
UUIDs turn up wherever something has to be named before anything can confirm the name is free. Application code mints them for rows it is about to insert, so the object has an identity before it has ever reached the database and a client can reference it while the write is still in flight. Distributed systems lean on them harder: a startup whose multi-tenant SaaS has several services writing into one table, a health or insurance system merging records that two providers created at the same moment, a mobile app that has to create records while the device is offline, and a queue that has to recognize the message it already processed — none of those can wait their turn for a shared counter. Version 5 covers a different need, which is a stable identifier derived from something you already have: the same document, the same URL or the same account always maps to the same UUID, so an import that matches records on that identifier can run twice without duplicating anything. Elsewhere they are simply the format a system demands — a correlation identifier threaded through logs and traces, a filename that will not collide when uploads from a thousand users land in one bucket, a Windows registry key, a test fixture that has to look like real data.
A few honest limits are worth knowing. One batch is one version: the value in Version applies to everything in it, so a run of v4s and a run of v7s are two batches. This is a generator, not an inspector — pasting a UUID in to read back its version or its timestamp is not something this page does. Save to File writes a plain text file rather than CSV or JSON. Version 7 openly reveals when it was created, to the millisecond, which is a real trade rather than a flaw, and version 1 leaks time in the same way; if that is a problem for your data, version 4 is the version that tells nobody anything. Two special values from the standard are not versions and so are not options in Version, but you can copy them from here: the nil UUID, 00000000-0000-0000-0000-000000000000, and the max UUID, ffffffff-ffff-ffff-ffff-ffffffffffff. Everything on this page follows RFC 9562, the specification that replaced RFC 4122 in 2024, so the output is standard UUID text that libraries and databases read — although a particular API may still accept only certain versions or one written form. Inside those limits the guarantee is a strong one: every identifier is built to the standard on your own machine and never sent to our server, and every random part of it comes from a cryptographically secure source.