UUID Generator

UUID v4 is a universally unique identifier generated using cryptographically secure random numbers. It contains 122 random bits and 6 fixed bits (4 for version, 2 for variant). The probability of generating a duplicate is astronomically low — you would need to generate 2.71 quintillion UUIDs to have a 50% chance of a single collision.

While not mathematically guaranteed to be unique, UUID v4 uses 122 random bits, giving 5.3 × 10³⁶ possible values. The chance of collision is so vanishingly small that it’s considered safe for virtually all applications. For context, you could generate 1 billion UUIDs per second for 85 years before having a 50% probability of a single duplicate.

Yes. All UUIDs are generated entirely in your browser using the Web Crypto API (crypto.randomUUID()). No data is sent to any server — the tool works completely offline once loaded.

UUID (Universally Unique Identifier) and GUID (Globally Unique Identifier) are essentially the same thing. GUID is the term used by Microsoft, while UUID is the standard term used in RFC 4122 and most other systems. They follow the same format and generation rules.

UUIDs work well as primary keys in distributed systems where you need to generate IDs without database coordination. However, random UUIDs (v4) can cause index fragmentation in B-tree indexes. Consider UUID v7 (time-ordered) for better database performance, or use UUIDs as secondary identifiers alongside auto-increment primary keys.

Some systems require compact identifiers without hyphens (32 characters instead of 36). Removing hyphens saves storage space in databases and makes UUIDs easier to use in URLs, filenames, and CSS class names. The UUID remains the same value regardless of formatting.

crypto.randomUUID() is a Web API that generates a UUID v4 string using the browser’s cryptographically secure pseudorandom number generator (CSPRNG). It’s supported in all modern browsers and is the recommended way to generate UUIDs in JavaScript.

Yes! This tool lets you generate up to 1,000 UUIDs at once. Enter your desired count, click Generate, and copy individual UUIDs or the entire list. All generation happens instantly in your browser.

UUID v7 is the newest standard (RFC 9562, May 2024) that encodes a 48-bit Unix millisecond timestamp at the start, followed by 74 random bits. Because the timestamp is leading, v7 UUIDs sort correctly by creation time as both binary and string values. This makes them ideal for database primary keys: B-tree indexes stay healthy because every new insert appends to the right side, avoiding the page splits and cache misses that random v4 primary keys cause at scale.

For database primary keys and any case where inserts should be time-ordered: yes, significantly. For general-purpose random IDs where you don't want creation time leaking, v4 is still the right pick. Both are secure and collision-safe; v7 trades a bit of information leakage for a lot of database performance.

UUID v2 is the 'DCE Security' variant — it replaces part of a v1 timestamp with a POSIX UID or GID. It's defined in the original spec but essentially nobody uses it today. Most UUID libraries don't even implement v2. You can safely ignore it.

Both generate deterministic UUIDs by hashing a namespace UUID plus a name string — feed in the same inputs, get the same UUID every time. v3 uses MD5, v5 uses SHA-1. v5 is strictly preferred for new code; v3 only exists for legacy compatibility. Neither is cryptographically secure against deliberate collision attacks, but they're fine for generating deterministic IDs from known inputs like URLs or DNS names.

v6 is a fixed version of v1 that reorders the timestamp bits so v6 UUIDs sort lexicographically by time. v8 is an explicit 'custom' version: it lets you define your own 122-bit payload while keeping the UUID shape and version/variant bits. Both were introduced in RFC 9562 (2024). v6 is rarely used outside of v1 migrations; v8 is useful when you need to embed your own identifier scheme into a UUID-compatible format.

The Nil UUID is all zeros (00000000-0000-0000-0000-000000000000), used as a sentinel for 'no value' or 'unset'. The Max UUID is all ones (ffffffff-ffff-ffff-ffff-ffffffffffff), added in RFC 9562 as a counterpart sentinel for 'maximum value'. They're reserved values — never generate them as real identifiers.

Only if the implementation uses your real MAC. Modern libraries (including this tool) generate a random 48-bit node value with the multicast bit set, which signals 'this is not a real MAC address'. That preserves the v1 format without leaking host identity. But if you care about host privacy, just use v4 or v7 — no node field at all.

Theoretically yes, practically no for random versions. v4 has 2¹²² possible values — you'd need to generate roughly 2.7 × 10¹⁸ UUIDs to have a 50% chance of a single collision (birthday problem). v7 has 74 random bits per millisecond, meaning you'd need ~5.4 billion generations in the same millisecond before collision becomes likely. Real systems have never observed v4 or v7 collisions. Only v3/v5 can collide in practice, and only if the same namespace + name is hashed twice.

Binary (16 bytes) is much more space-efficient than strings (36 bytes) and uses indexes more efficiently. Postgres has a native uuid type that stores binary. MySQL 8+ has BINARY(16) or UUID_TO_BIN(). SQL Server has uniqueidentifier. For v7 specifically, make sure your database preserves byte order so the time-ordered property survives storage and sorting.

Both are valid and represent the same value. RFC 9562 recommends lowercase but requires parsers to accept both. Stick to one style within a codebase for consistency. Postgres stores them in lowercase by default; .NET/Microsoft code often uses uppercase.

UUID stands for 'Universally Unique Identifier'. It's a 128-bit value formatted as 32 hexadecimal digits grouped as 8-4-4-4-12 with hyphens (like 550e8400-e29b-41d4-a716-446655440000). The format is defined by RFC 9562 (and previously RFC 4122).

A UUID is 128 bits = 16 bytes. In its canonical string form it's 36 characters (32 hex digits + 4 hyphens). Without hyphens it's 32 characters. Stored as binary in a database it takes only 16 bytes, which is half the space of the 36-char string form.

Yes — they're the same 128-bit format. GUID (Globally Unique Identifier) is Microsoft's name for it; UUID (Universally Unique Identifier) is the RFC/ISO name. Any UUID is a valid GUID and vice versa, though Microsoft code sometimes displays them with uppercase letters or in a mixed-endian byte order internally.

The UUID space has 2¹²⁸ possible values — that's 340,282,366,920,938,463,463,374,607,431,768,211,456 combinations. Each version reserves some bits for version and variant, but v4 still has 2¹²² random values available — more than enough for any practical system.

Only for certain versions. v7 sorts perfectly by creation time as both binary and string (it was designed for this). v6 also sorts correctly after its byte reordering. v1 does NOT sort by time — the timestamp fields are interleaved in a way that breaks lexicographic order. v4, v3, v5, v8 are not time-based and have no meaningful ordering.

Use a regex or your language's built-in UUID parser. In JavaScript: /^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}$/.test(str). In Python: try uuid.UUID(str) — it raises ValueError if invalid. Our built-in Inspector above is also a free validator: paste any string and it'll tell you.

Astronomically low. With 2¹²² random values, the birthday paradox gives roughly a 50% chance of a collision after generating 2.71 × 10¹⁸ UUIDs. That's 2.7 quintillion. At 1 billion UUIDs per second, you'd need 85 years to hit 50%. For any practical application, treat collisions as impossible.

Yes — the first 48 bits of a v7 UUID are milliseconds since the Unix epoch. Take the first 12 hex characters (removing hyphens), parse as integer, that's your Unix milliseconds. The Inspector above does this automatically for any v1, v6, or v7 UUID.

Use v7. v7 is nearly always better for database primary keys because its time-ordered structure keeps B-tree indexes healthy and inserts cheap. v4 is fine for secondary identifiers or anywhere you want to hide creation time, but in 2025+ there's no reason to pick v4 for a new primary key column.

They're functionally almost identical — both are 128-bit time-ordered IDs with a ~48-bit ms timestamp and ~80 bits of randomness. The differences: (1) encoding — UUID v7 uses hex with hyphens (36 chars), ULID uses Crockford Base32 (26 chars); (2) ecosystem — UUID is universally supported, ULID is niche; (3) variant/version bits — UUID v7 carves out 6 bits for RFC compliance, ULID doesn't. Prefer v7 for new systems due to universal tooling support.

Yes. It's a standardized browser/Node API that uses the underlying cryptographic random generator (the same one that powers WebCrypto and SubtleCrypto). It was added to WHATWG HTML spec in 2021 and has been available in Node 14.17+, Chrome 92+, Safari 15.4+, Firefox 95+.

No — they encode fundamentally different information. v4 is pure randomness; v7 has a timestamp baked in. You can't extract a timestamp from v4 that wasn't there, and you can't regenerate the exact same v7 without knowing the original timestamp. If you want to migrate, you have to generate fresh IDs.

No timezone — v7 stores milliseconds since Unix epoch (UTC, by definition). When you decode it, interpret it as UTC and convert to your local timezone for display. Timezone information is never part of the UUID.

It doesn't — v1 UUIDs have a 1 in the 13th position (first character of the 3rd group). If you're seeing a 4, that's a v4 UUID. The digit at position 13 (the 'M' in xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx) always reflects the version number.

JSON has no native UUID type — they're serialized as strings. Most languages automatically quote UUIDs when encoding to JSON and parse them back to their UUID type on the way in. Example: { "id": "550e8400-e29b-41d4-a716-446655440000" }. The canonical form (with hyphens, lowercase) is standard for JSON APIs.

For non-security-critical session identifiers, yes — a v4 UUID provides 122 bits of entropy, far exceeding the 64-bit minimum recommended for session IDs. For stronger security, use a longer opaque random token (256 bits) or a signed JWT. Never use v1/v6/v7 for session tokens because their timestamps reveal session-start time.

The canonical UUID format uses hex digits and hyphens only, all of which are URL-safe (they don't need percent-encoding). You can drop UUIDs directly into URL paths and query strings without issue. The 36-char length is the only drawback for user-facing URLs.

No. RFC 9562 (2024) defines v1 through v8 and doesn't reserve numbers above v8. Any future UUID versions would need a new RFC. In practice v4 and v7 cover nearly all use cases, so demand for new versions is low.