Generate version-4 UUIDs — one or a hundred — straight from your browser's cryptographic random generator. Standard, uppercase or hyphen-free, never transmitted or stored.
Version-4 UUIDs from your browser's cryptographic random generator (crypto.getRandomValues) — generated locally, never transmitted, never stored.
What this free tool is great for: a quick, one-off job with no signup — it runs entirely in your browser, so nothing leaves your device and there's nothing to manage.
Its honest limit: it produces a one-off output — it won't store, track, brand or manage them at scale, and it can't tell you what happens after you share it.
A UUID — universally unique identifier — is a 128-bit value written as 36 familiar characters: 8-4-4-4-12 hex digits. Its superpower is coordination-free uniqueness: any machine, anywhere, can generate one right now without asking a central authority, and it will not collide with anyone else's. That property quietly powers modern systems — records created offline and synced later, distributed services naming things independently, files and sessions and orders that need identity before any database has assigned a number. This generator produces version-4 (random) UUIDs from your browser's cryptographic randomness, locally: nothing is sent, logged or remembered, which is exactly the trust level an identifier generator should require — none.
"Universally unique" sounds like marketing, so here's the real math: a v4 UUID contains 122 random bits, giving about 5.3 undecillion possible values (5.3 × 10³⁶). Collision odds follow the birthday paradox, and the numbers stay absurd: generate a billion UUIDs per second for a century and the probability of a single collision remains around one in a few billion. Practically: collisions come from broken randomness or copy-paste bugs, never from chance. The one honest caveat — the guarantee leans on cryptographic randomness. This tool uses crypto.getRandomValues, the browser's CSPRNG; ancient generators using Math.random() gave far weaker guarantees, which is a real historical footnote, not paranoia.
The version digit (the character after the second hyphen — always 4 here) tells you the recipe. V4 is pure randomness and the sensible default for almost everything. V1 embeds a timestamp and machine identifier — sortable-ish, but it leaks when and roughly where the ID was made, which has bitten people. V5 hashes a name within a namespace, producing the same UUID for the same input — deliberately deterministic, useful when an external key must map stably to an ID. The newer v7 puts a timestamp in front of randomness so IDs sort by creation time — increasingly popular for database keys. Rule of thumb: v4 unless you have a stated reason, and if the reason is "sortable database keys", look at v7.
The classic alternative is the auto-incrementing integer: 1, 2, 3… Compact, human-readable, sortable — and leaky. Sequential IDs in URLs reveal your volume (order #1043 tells competitors how many orders you have), invite enumeration (change the number, see someone else's invoice — the classic IDOR vulnerability), and require central coordination that distributed systems can't afford. UUIDs fix all three: unguessable, disclosure-free, coordination-free. Their costs are equally real: 36 characters is unwieldy in URLs and support calls, and purely random keys fragment database indexes at scale (the v7 motivation). Many mature systems use both — an internal integer for the database, a UUID for anything public-facing.
Because UUIDs are unguessable, they get misused as passwords, API keys and session tokens — and that's a category error worth naming. An identifier's job is naming things; a secret's job is proving authority, with rotation, expiry, revocation and storage discipline around it. A UUID in a URL is fine as an unguessable reference (the share-link pattern), but authorisation must still be checked server-side — "knows the UUID" is not "is allowed". And v1 UUIDs, with their embedded timestamps and machine bits, should never guard anything. If you're reaching for a UUID because you need a token, reach for a real token generator with an expiry instead.
The dashes are punctuation, not data — 550e8400-e29b… and 550e8400e29b… are the same value, and systems differ in which spelling they store. Casing is similarly cosmetic: the spec says lowercase for display, but comparisons should be case-insensitive, and plenty of databases uppercase everything. This generator's format options exist for exactly those integrations: standard lowercase for most uses, no-hyphens for systems that store the bare 32 hex characters, uppercase for legacy tools that insist. When matching UUIDs across systems fails, normalise both sides (lowercase, dashes stripped) before concluding the IDs actually differ — formatting mismatches masquerade as data bugs weekly somewhere.
UUIDs aren't only for programmers. They make excellent correlation IDs to quote in support tickets ("reference: 3f2a…") so both sides discuss the same event. They're safe filenames for uploads, immune to collisions and to users named "final_v2 (1).pdf". They label test data unmistakably, tag QR batches, key spreadsheet rows that sync across tools, and identify webhook deliveries for idempotency — the receiver skips any UUID it has already processed, which is the polite way to survive duplicate deliveries. Anywhere you need "a name that's certainly new and reveals nothing", this is the tool, and now it's one click away.
The 25-and-100 options exist for a practical pattern: pre-assigning identifiers in bulk. Seeding a spreadsheet with stable row-IDs before it syncs to three other tools; labelling a batch of physical assets or QR codes; preparing test fixtures that need obviously-unique keys. Generate a column's worth, paste once, and every downstream system inherits collision-free identity. One habit makes this durable: treat the UUID column as immutable from that moment — the whole value of a stable identifier evaporates the first time someone regenerates it to "clean things up". If a record's UUID must ever change, that's not cleanup, that's a new record — and the distinction is exactly what keeps cross-tool syncs from silently duplicating your data.
A UUID is one line of the systems it lives in: the API that issues them, the database that keys on them, the webhook handler that dedupes by them. Building those pieces used to mean local environments and deployment yaks; that's where Replit does more — a full development environment in the browser whose AI agent turns "build me a small API that stores these records with UUID keys" into working, deployed code in an afternoon. Generate identifiers here when you need a handful; when you notice you're designing the system around them, that's the moment to go build it — the barrier has never been lower.
Theoretically yes, practically no: 122 random bits mean that even generating a billion per second for a century leaves collision odds around one in billions. Real-world collisions come from broken randomness, not chance.
v4 (random — what this tool makes) unless you have a stated reason. Need database keys that sort by creation time? Look at v7. Need the same input to always yield the same ID? That's v5.
No — identifiers name things; secrets prove authority and need expiry, rotation and revocation. A UUID works as an unguessable reference (share links), but authorisation must still be checked server-side.
No — they're formatting. Compare case-insensitively and, when matching across systems, normalise both sides (lowercase, hyphens stripped) before concluding the IDs differ.
Blogger, teacher or toolmaker? Put this calculator on your own page — free forever, no strings. Copy the snippet below (the credit link is appreciated and keeps the tool free):
This tool is free and runs entirely in your browser. The link above is an affiliate link: we may earn a commission if you sign up, at no extra cost to you, and it never changes our honest take.