A JavaScript-generated UUID is a 128-bit identifier written as 32 hexadecimal digits in the canonical 8-4-4-4-12 pattern — for example f47ac10b-58cc-4372-a567-0e02b2c3d479 — where the 13th hex digit is fixed to 4 (the version) and the 17th is fixed to 8, 9, a, or b (the variant), so 6 of the 128 bits are reserved and 122 remain free for randomness. That 122-bit payload is what makes a UUID v4 practically collision-free at any volume a real application will produce. In JavaScript, the safe way to fill those 122 bits is the Web Crypto API's crypto.getRandomValues, which pulls from the browser's cryptographically secure random number generator. The shorthand "UUID" stands for Universally Unique IDentifier, and the v4 variant is the fully random flavor defined in RFC 4122 and its 2024 replacement RFC 9562 — the kind you can mint independently on any device, anywhere, without phoning home to a central registry. That coordination-free property is exactly why so many JavaScript stacks default to v4 for database keys, idempotency tokens, log correlation IDs, and file names.
What a UUID v4 Actually Looks Like
Each v4 UUID is a 128-bit value rendered as 32 hexadecimal characters grouped into five blocks of 8, 4, 4, 4, and 12 digits, separated by hyphens. The canonical text form is therefore 36 characters long — 32 hex digits plus 4 hyphens. Inside those 128 bits, exactly 6 are non-random: 4 bits encode the version, and 2 bits encode the variant. Because v4 stores the version 4 in the high nibble of the 13th hex digit, that digit is always the literal character 4. The variant bits sit in the high two bits of the 17th hex digit, which is therefore always one of 8, 9, a, or b. Anyone can recognize a v4 UUID by scanning for those two positions — that is the entire spec fingerprint.
Spotting the version and variant also lets you tell v4 apart from the other UUID flavors at a glance. The 13th hex digit encodes 1, 3, 4, 5, or 7 depending on the version; the 17th-digit rule applies across all versions because the variant field is shared. The hyphen-grouped shape, the fixed version nibble, and the fixed variant nibble together define what "looks like a v4" really means in code review, in a log pipeline, or in a database column constraint.
Why the Random Source Matters in JavaScript
The 122 random bits in a v4 UUID have to come from somewhere, and the source matters a great deal. A quick JavaScript snippet can produce a string that looks like a UUID by calling Math.random() and formatting the output, but Math.random is not cryptographically secure: it is deterministic enough that an attacker who has seen a few outputs can sometimes predict later ones, and the algorithm varies across engines. The browser-safe way is crypto.getRandomValues, which draws from the same CSPRNG that powers TLS handshakes and other security-critical APIs.
This is the core of why the UUID Generator produces identifiers that are safe to expose in URLs, logs, and client-side code: every value is minted from crypto.getRandomValues inside your tab. With 122 bits drawn from a CSPRNG, each output is statistically independent of the previous one — there is no shared seed, no clock, no MAC address, no namespace mixed in. That property is what lets two unrelated services mint IDs at the same instant and still be confident they will not collide. The cost of skipping the CSPRNG is not just theoretical: a predictable identifier can be guessed, replayed, or correlated across requests, which is exactly the failure mode security reviews flag when they reject identifiers built on weak randomness.
Generate UUIDs in Your Browser
The fastest way to produce a single UUID or a batch of UUIDs without writing a single line of code is the in-browser UUID Generator. The whole flow runs locally, so the identifiers are ready before any network round trip.
- Open the UUID Generator and enter how many UUIDs you want, from 1 up to 100.
- If your database column or code style needs a different text form, toggle uppercase to capitalize the hex digits, or toggle remove hyphens to drop the four separators and produce a continuous 32-character string.
- Click Generate. The list refreshes with fresh v4 UUIDs drawn from your browser's CSPRNG.
- Hover any row and copy that single UUID, or use Copy all to grab the entire batch in one clipboard operation.
Because the tool runs in your tab, you can repeat the step indefinitely: each click of Generate produces an entirely new batch, and you can change the format toggles between runs without losing previously generated values. For developers who also want to test the values inside actual code, the JavaScript Playground is a useful companion — paste a generated UUID into a snippet and exercise it against your real validation logic before you ship.
Choosing the Output Format
Three toggles shape the text a UUID Generator hands back. None of them changes the underlying 128-bit value, so the choice is purely about what your downstream system expects.
| Toggle | Text form | Example | Same value? |
|---|---|---|---|
| Default | Lowercase, hyphenated | f47ac10b-58cc-4372-a567-0e02b2c3d479 | Yes |
| Uppercase | Uppercase hex, hyphenated | F47AC10B-58CC-4372-A567-0E02B2C3D479 | Yes |
| No hyphens | Lowercase, no separators | f47ac10b58cc4372a5670e02b2c3d479 | Yes |
| Both | Uppercase hex, no separators | F47AC10B58CC4372A5670E02B2C3D479 | Yes |
Database columns often store the canonical 36-character form because it matches the spec, but some token systems, header values, and embedded identifiers prefer the 32-character no-hyphen form to save space or to match a fixed-width field. If your stack compares UUIDs with case-insensitive equality, the uppercase option is harmless; if it compares them with case-sensitive equality, stick with lowercase so you do not end up with two strings that look different but represent the same identifier.
When UUID v4 Is the Right Choice
Version 4 is the right default for any identifier that needs to be minted independently by two systems without coordinating — exactly the situation JavaScript developers hit constantly.
| UUID version | Source of bits | Typical JavaScript use case |
|---|---|---|
| v1 | Timestamp + MAC address | Rarely used in JS; can leak host info |
| v3 | MD5 hash of a namespace + name | Deterministic IDs from a known input |
| v4 | 122 random bits from a CSPRNG | Database keys, idempotency tokens, trace IDs, file names |
| v5 | SHA-1 hash of a namespace + name | Same as v3, with a stronger hash |
| v7 | Millisecond timestamp + random tail | Time-ordered keys for index locality |
The practical cases line up with v4: distributed and offline-first systems that need to create records before they sync, idempotency keys that prevent duplicate API calls, correlation IDs that thread through a log pipeline, and object or file names that must not collide across services. For each of these, the absence of any clock, MAC address, or namespace input is a feature — there is simply nothing to leak and nothing to coordinate.
The one exception worth flagging is UUIDv7. If you store UUIDs in a database that is indexed by primary key and you care about index locality — meaning new writes always land near the end of the index rather than scattered randomly — v7's time-ordered prefix is the better choice. For unordered uniqueness, which is the common case, v4 is still the default.
Browser-Only Generation and Security
Every UUID the generator produces is computed locally in your browser tab using crypto.getRandomValues. Nothing you generate or copy is transmitted to a server, so the tool is safe to use for production identifiers and internal secrets alike. That guarantee falls out of the implementation, not out of a privacy promise: the page never opens a network connection to a UUID backend, and the clipboard output is the only place the value ever travels.
To make the collision math concrete, take 122 random bits. The birthday bound — the point at which the probability of at least one duplicate in a set reaches 50% — is about 2.71 × 10^18. Divide that by 10^9 UUIDs per second, then again by 31,536,000 seconds per year, and you get about 86 years of continuous generation at a billion UUIDs per second before a single duplicate becomes more likely than not. That is the underlying reason distributed systems treat v4 UUIDs as effectively unique without coordinating across machines, and it is exactly the property that makes them safe to mint in a browser tab.
For JavaScript developers, the practical takeaway is short. Skip Math.random() for anything that needs to be unguessable. Use crypto.getRandomValues() in code, and use the UUID Generator when you need a value faster than you can write the snippet — the output is the same 122-bit random identifier, just produced without a network round trip. If you need to verify the spec details, the canonical reference is RFC 4122, updated by RFC 9562, which defines exactly how the version and variant bits are set.