Generate cryptographically random v4 UUIDs instantly with this free online UUID generator. Bulk generate up to 100 UUIDs at once, copy individually or all together with one click, and download as a text file. Options include uppercase formatting, hyphen removal, and wrapping in curly braces for GUID-style output. This tool uses your browser's native crypto.randomUUID() API — the gold standard for cryptographically secure random ID generation. All UUIDs are generated entirely in your browser. Nothing is sent to a server. Works offline, no signup required.
UUIDs are the connective tissue of modern distributed systems. Every Stripe charge, every Auth0 session, every Slack message, every S3 multipart upload — they all carry a 128-bit identifier that was generated independently on whatever node happened to handle the request. That independence is the entire point: no central registry, no ID server, no race condition, no merge conflict. This guide walks through the full UUID specification family — RFC 4122 (the original 2005 standard) and RFC 9562 (its 2024 successor that introduced UUIDv7), the seven defined versions and what each is actually for, the index-fragmentation trap that hits every team eventually, and the language-by-language code you need to generate them safely.
A UUID is 128 bits, written as 32 hexadecimal characters split by hyphens into the canonical form xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx. The bytes are not random freeform — two specific positions encode the version and variant:
4 means random (v4), 7 means time-ordered (v7), 1 means timestamp+MAC, etc.10 (binary), so the hex is one of 8, 9, a, b. This identifies the UUID as RFC 4122/9562 (the "Leach-Salz" variant) versus older Microsoft/NCS variants.Because the version and variant nibbles eat 6 bits, a v4 UUID has 122 random bits, not 128. The collision math you might have seen — "you'd need to generate 2.71 quintillion UUIDs to have a 50% chance of one collision" — is based on those 122 bits applied to the standard birthday-paradox formula n ≈ 1.177 × √(2^122).
| Version | Mechanism | Sortable? | Privacy concern | Use it for |
|---|---|---|---|---|
| v1 | 60-bit timestamp + 14-bit clock seq + 48-bit MAC | Yes | Leaks server MAC and time | Legacy systems only — avoid in new code. |
| v2 | DCE Security (POSIX UID/GID) | Partially | Same as v1 plus user info | Defined but essentially unused. Skip. |
| v3 | MD5(namespace + name) | No | Deterministic | Content-addressed IDs where MD5 is OK. Use v5 instead. |
| v4 | 122 random bits | No | None | Default for the past 20 years. Still fine for primary keys at small-to-medium scale. |
| v5 | SHA-1(namespace + name) | No | Deterministic | Stable IDs derived from a name (DNS, URL, OID). |
| v6 | v1 with the timestamp bytes reordered for sortability | Yes | Same as v1 (MAC leak) | Migration path off v1. Most teams jump to v7 instead. |
| v7 | 48-bit Unix-millis timestamp + 74 random bits | Yes | Reveals creation time only | The new default for primary keys, log IDs, anywhere you want both uniqueness and time-locality. |
If you are starting a new project in 2026, default to v7. If you are stuck on a runtime that does not yet implement v7 (older language stdlibs), v4 is still safe — just be aware of the index-fragmentation cost at scale.
Databases store primary-key indexes as B-trees (or B+ trees). When IDs arrive in roughly sorted order — autoincrement integers, ULIDs, UUIDv7 — every new row inserts at the tail of the index, the page stays full, and the cache hit rate is high. When IDs are random — UUIDv4 — every insert lands in a different B-tree page. Pages split, rewrites cascade, and the tail of the working set blows out of memory. Real-world impact:
NEWSEQUENTIALID() exists exactly because random GUIDs hurt.The fixes, in order of preference: (1) UUIDv7, which preserves uniqueness while putting the high-order bits in time order; (2) ULID — same idea, different encoding; (3) store v4 UUIDs as native BINARY(16)/uuid columns rather than VARCHAR(36), halving size; (4) on MySQL, use UUID_TO_BIN(uuid, 1) which reorders v1 bytes for B-tree locality.
Always use a cryptographically secure RNG. Math.random(), java.util.Random, and rand() in C are not safe — they have predictable internal state and can collide.
// v4 — built in
const id = crypto.randomUUID();
// v7 — implement with crypto.getRandomValues
function uuidv7() {
const ts = BigInt(Date.now());
const rand = crypto.getRandomValues(new Uint8Array(10));
const b = new Uint8Array(16);
// 48-bit timestamp
for (let i = 0; i < 6; i++) b[i] = Number((ts >> BigInt(40 - i*8)) & 0xffn);
b.set(rand, 6);
b[6] = (b[6] & 0x0f) | 0x70; // version 7
b[8] = (b[8] & 0x3f) | 0x80; // variant 10
const h = [...b].map(x => x.toString(16).padStart(2,'0')).join('');
return `${h.slice(0,8)}-${h.slice(8,12)}-${h.slice(12,16)}-${h.slice(16,20)}-${h.slice(20)}`;
}import uuid
uuid.uuid4() # v4
uuid.uuid7() # v7 (Python 3.13+; on older, use the `uuid7` PyPI package)
uuid.uuid5(uuid.NAMESPACE_URL, "https://example.com/users/42") # v5import "github.com/google/uuid"
id4 := uuid.New() // v4
id7, _ := uuid.NewV7() // v7 (v1.6.0+)import java.util.UUID;
UUID id = UUID.randomUUID(); // v4
// v7 — needs a library, e.g. com.github.f4b6a3:uuid-creator
import com.github.f4b6a3.uuid.UuidCreator;
UUID v7 = UuidCreator.getTimeOrderedEpoch();use uuid::Uuid;
let id = Uuid::new_v4();
let v7 = Uuid::now_v7(); // requires the `v7` featureuse Symfony\Component\Uid\Uuid;
$v4 = Uuid::v4();
$v7 = Uuid::v7();require 'securerandom'
SecureRandom.uuid # v4
# v7 — needs a gem like `uuidx`
require 'uuidx'
Uuidx.v7SELECT gen_random_uuid(); -- v4 (built-in since 13)
-- v7 — install pg_uuidv7 extension or upgrade to PG 18 which adds uuidv7()VARCHAR(36). 36 bytes for the string vs 16 bytes for native binary. Postgres has uuid, MySQL 8 has BINARY(16) with UUID_TO_BIN(), SQL Server has uniqueidentifier. Use them./^[0-9a-f-]{36}$/ accepts garbage like aaaa-aaaa-.... The correct shape requires the specific positions and the variant nibble: /^[0-9a-f]{8}-[0-9a-f]{4}-[1-7][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i.Math.random(). The classic "xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx".replace(...) snippet from Stack Overflow uses Math.random(), which is not cryptographically secure. Use crypto.randomUUID() in any browser since 2021.| Format | Bits of randomness | Sortable? | Length | Standard? |
|---|---|---|---|---|
| UUIDv4 | 122 | No | 36 chars (32 hex + 4 hyphens) | RFC 4122 / 9562 |
| UUIDv7 | 74 + 48-bit time | Yes | 36 chars | RFC 9562 |
| ULID | 80 + 48-bit time | Yes | 26 chars (Crockford base32) | De-facto, no RFC |
| NanoID (default) | 126 (21 chars × 6 bits) | No | 21 chars | De-facto |
| CUID2 | ~256 (sha-3 derived) | No | 24 chars (configurable) | De-facto |
Practical guide: use UUIDv7 if your stack and database support it. Use ULID if you want a shorter, more URL-friendly time-ordered ID. Use NanoID for short opaque IDs (8–12 chars) where 128 bits is overkill. Use UUIDv4 if interop with old systems matters more than performance.
"UUIDv7" search volume has overtaken "UUID v4" generators in 2026 because RFC 9562 (May 2024) made it a first-class standard, and major databases (PostgreSQL 18, MySQL 8.4, SQL Server 2025) ship native v7 support. The right generator is no longer just "v4 random" — you need v4 for randomness-critical IDs and v7 for everything stored in a B-tree index. Here is how the most-used UUID generators compare in 2026:
| Tool | UUIDv7 | v4 / v1 / v5 | Bulk (100+) | Browser-only | Cost |
|---|---|---|---|---|---|
| FreeDevTool UUID Generator | Yes | v4 + v1 + v5 | Up to 1,000 | Yes | Free |
| uuidgenerator.net | Yes (added 2024) | v4 + v1 | Up to 100 | Yes | Free, ad-funded |
| uuid.rocks | Yes | v4 + v7 + ULID + nanoid | Up to 100 | Yes | Free |
| online-toolz UUID | No (v4 only) | v4 only | Up to 50 | Yes | Free, ad-funded |
uuid npm library | v7 added in v10 | All versions | Programmatic | Local install | Free, OSS |
PostgreSQL gen_random_uuid() | v7 native in PG 18 | v4 standard | Programmatic | Server-side | Free |
UUIDv7 is a time-ordered UUID — the first 48 bits are a Unix-millisecond timestamp, then 74 random bits, plus version/variant fields. It is identical in shape to v4 (same 36-char hex format) but sorts chronologically. Switch from v4 → v7 whenever the UUID is stored in a B-tree index (Postgres, MySQL, SQL Server, MongoDB _id). Random v4 IDs scatter writes across the index and cause page splits — measurements on InnoDB show v4 inserts ~3× slower than v7 at 10M+ rows. Keep v4 only when the ID must NOT leak time information (security tokens, share-by-URL secrets where a guess of the timestamp helps an attacker). For everything else in 2026, default to v7.
Three rules. One: use a CSPRNG, not Math.random(). The browser's crypto.randomUUID() calls a NIST-validated CSPRNG; this generator uses it directly. Two: never seed v4 from a timestamp or username — that defeats the 122 random bits. Three: never use a v4 UUID as a session token or password reset link. v4 is unique, but it is not a secret-strength random — only 122 bits of entropy after the version bits, no padding, and brute-forceable for short-lived secrets. Use a 256-bit CSPRNG token (Node's crypto.randomBytes(32).toString('hex'), the Hash Generator's SHA-256 of a random nonce, or a JWT signed with a secret key) for anything that grants access. UUIDs are identifiers, not credentials.
| Format | Length | Ordered | Standard | Best for |
|---|---|---|---|---|
| UUIDv7 | 36 chars (or 16 bytes) | Yes (ms) | RFC 9562 (2024) | Database PKs in 2026 |
| UUIDv4 | 36 chars | No | RFC 4122 (2005) | Truly random IDs only |
| ULID | 26 chars (Base32) | Yes (ms) | de-facto, no RFC | URL-safe ordered IDs pre-2024 |
| NanoID | 21 chars (configurable) | No | npm spec | Short URL slugs |
| CUID2 | 24 chars | Yes | npm spec | Collision-resistant, host-fingerprinted |
| Snowflake | 64-bit int | Yes | Twitter spec | High-volume distributed systems |
Decision tree: B-tree DB primary key in 2026 → UUIDv7. Pre-RFC-9562 codebase that already uses ULID → keep ULID (interop is fine, just don't mix). Public URL slug where you want short → NanoID. Internal high-throughput service with Snowflake already in place → keep Snowflake. Random secret/token → not a UUID at all, use a 256-bit CSPRNG nonce.
Pair the UUID generator with the Complete UUID Guide for the deeper RFC 9562 / RFC 4122 walk-through, the Hash Generator for SHA-1 in v5 namespace UUIDs, and the Unix Timestamp Converter for decoding the leading timestamp bytes of any v7 UUID.
UUIDs (or GUIDs) are 128-bit identifiers used as primary keys, request IDs, idempotency tokens, and feature-flag identifiers. The generator produces RFC 4122 v4 UUIDs (random) by default — cryptographically random via crypto.getRandomValues(), generated entirely in your browser. No collisions in practice; no network calls.
550e8400-e29b-41d4-a716-446655440000), no hyphens, uppercase, or wrapped in braces for older Microsoft systems.UUIDv7 (time-ordered) or a ULID.VARCHAR(36) when your DB has a native type. Postgres has uuid, MySQL 8 has UUID_TO_BIN() for binary 16-byte storage. Native types are 2.25× smaller and faster.Math.random(). Not cryptographically secure — collisions are theoretically possible across enough generations. Use crypto.randomUUID() (built-in to modern browsers and Node 14+).xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. It is designed to be unique across distributed systems without a central coordinator. UUID is standardized in RFC 4122 and used in databases, APIs, file systems, and distributed architectures worldwide.
crypto.randomUUID() — a cryptographically secure random number generator — not Math.random().
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx format.
crypto.randomUUID()require('crypto').randomUUID()import uuid; str(uuid.uuid4())import "github.com/google/uuid"; uuid.New().String()SELECT gen_random_uuid();SELECT UUID();
All tools run in your browser, no signup required, nothing sent to a server.