UUID Generator

UUID Generator - Generate Unique Identifiers Online

A UUID is a 128-bit identifier defined by RFC 4122 (1999) and extended by RFC 9562 (2024), guaranteed unique not by central coordination but by the size of its address space — 2^122 valid v4 values means that generating one billion per second for 85 years would still only give you a 50% chance of a single collision. This generator produces every version that has practical use in 2026: v1 (timestamp + MAC, mostly deprecated because it leaks the host MAC and creation time), v4 (122 random bits, the default for any identifier that should reveal nothing), v5 (deterministic, derived by SHA-1 hashing a namespace UUID with a name string — useful for stable IDs from URLs), v7 (the modern winner for database primary keys: a 48-bit millisecond timestamp prefix makes inserts append at the end of a B-tree index like an auto-increment integer, while 74 random bits keep IDs unguessable), and the Nil UUID 00000000-0000-0000-0000-000000000000 as a NULL sentinel. Randomness comes from the Web Crypto API (crypto.randomUUID for v4, crypto.getRandomValues for v7) which is cryptographically secure — strong enough for session tokens and password-reset links, unlike Math.random or older PHP uniqid which have been broken in practice. Output formatting (uppercase, no hyphens, Microsoft-style braces) is fully optional; all generation runs in your browser with zero network calls.

Is UUID v4 truly unique?

UUID v4 is not guaranteed unique — it is probabilistically unique to the point where collisions are not a practical concern. A v4 UUID has 122 random bits (6 bits are reserved for the version and variant markers), giving 2^122 possible values (about 5.3 × 10^36). By the birthday paradox, you would need to generate about 2.71 quintillion UUIDs to have a 50% chance of a single collision — at one billion per second, that takes 85 years. For comparison, every grain of sand on Earth is roughly 7.5 × 10^18, so the UUID v4 space is more than 10^17 times larger. The catch is the quality of your random source: a weak PRNG (Math.random instead of crypto.getRandomValues, or a misseeded RNG on first boot) shrinks the effective entropy dramatically. This generator uses the Web Crypto API for cryptographic-quality randomness.

Which UUID version should I use: v1, v4, v6, or v7?

UUID v1 (timestamp + MAC address, RFC 4122) is mostly deprecated because it leaks the host MAC and reveals creation time. UUID v4 (random, RFC 4122) is the default choice for general identifiers — IDs that should reveal nothing. UUID v6 reorders v1's timestamp bytes to be sortable but still leaks MAC. UUID v7 (RFC 9562, finalized 2024) is the modern winner for database primary keys: the first 48 bits are a Unix millisecond timestamp followed by 74 random bits, so v7 IDs sort chronologically and play nicely with B-tree indexes while still being unguessable. UUID v8 is a free-form custom version reserved for application-specific layouts. For new systems in 2026, default to v7 for database keys, v4 for anything that should leak no information.

What are the version and variant bits, and where are they in the UUID?

A UUID is rendered as eight-four-four-four-twelve hex digits (xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx). The first nibble of the third group (M) is the version: 1, 4, 7, etc. The first two bits of the fourth group (N) encode the variant: 10 in binary (so the first character is always 8, 9, a, or b) marks RFC 4122 / RFC 9562 UUIDs. This is why a valid v4 UUID always has the pattern xxxxxxxx-xxxx-4xxx-[89ab]xxx-xxxxxxxxxxxx. A quick regex sanity check rejects malformed IDs before they reach your database. The reserved bits cost six total — leaving 122 random bits in v4 — and ensure UUIDs from different specs (Microsoft's old GUID variant, future versions) are distinguishable without ambiguity.

Should I use UUIDs as primary keys in my SQL database?

It depends on the database and the UUID version. v4 UUIDs as primary keys hurt InnoDB and SQL Server performance significantly: random insert positions cause page splits and clustered-index fragmentation, and the 16-byte size doubles the storage of every secondary index versus a 4-byte int. PostgreSQL with the uuid type and a btree index handles v4 better but still loses some sequential-insert advantages. UUID v7's monotonically increasing prefix solves the fragmentation problem — inserts append at the end of the index just like an auto-increment integer. The wins of UUIDs: globally unique without coordination, safe to merge databases, no enumeration attacks on /users/123 URLs, distributed-system friendly. The wins of bigints: half the size, faster joins, simpler debugging. For new schemas, default to UUID v7 unless the table is small or hot-path latency dominates.

What is the difference between a UUID and a GUID?

Functionally none — "GUID" (Globally Unique Identifier) is Microsoft's name for the same 128-bit identifier defined in RFC 4122. The encoded byte layout is identical: 16 raw bytes. The textual rendering is the same: eight-four-four-four-twelve hex. The slight historical difference is byte order: Microsoft's legacy GUID format stored the first three fields in little-endian (Data1, Data2, Data3) on disk, while RFC 4122 specifies big-endian (network byte order). This means a binary GUID exported from a Windows COM API and read back as bytes on a Unix system will appear byte-swapped in the first 8 bytes. Modern systems normalize on the textual hex representation, which is canonical and unambiguous. For Microsoft SQL Server's uniqueidentifier type, the on-disk bytes are still in the legacy order — sort behavior differs from PostgreSQL UUID.

Can I shorten a UUID for use in URLs without losing uniqueness?

Yes — the 128 bits of a UUID can be encoded more compactly than the 36-character hex form (with hyphens) by switching alphabets. Base64-encoded UUID is 22 characters (24 with padding), URL-safe Base64 with stripped padding is 22 characters, and Base58 (no confusable characters like 0/O/l/I) is 22 characters. Crockford Base32 is 26 characters and human-friendly. These are all lossless: the receiver decodes back to the same 16 bytes. NEVER chop off characters — that destroys the uniqueness guarantee. A 64-bit hash like FNV or xxHash from the UUID gives 16-character output but trades collisions for length and is no longer a UUID. Alternatives like Nano ID or ULID give similar URL-friendliness from the start without the UUID translation step. ULID even uses sortable Crockford Base32 by design.

Are UUIDs cryptographically secure or safe for security tokens?

UUID v4 generated from a cryptographic RNG (Web Crypto, /dev/urandom, BCryptGenRandom) has 122 bits of entropy, which exceeds the 128-bit-symmetric guideline minus the 6 fixed version/variant bits. That is enough for session tokens, password-reset links, and idempotency keys — comparable to a 21-character random Base64 string. The caveat: UUIDs from older language libraries that rely on Math.random or time-based seeding are NOT cryptographically secure and have been broken in practice (predict-the-next-UUID attacks against PHP's uniqid, Java's java.util.UUID with insecure seeds). Verify your source uses crypto.randomUUID (browser/Node 19+), uuid.uuid4 backed by os.urandom (Python), or System.Security.Cryptography (.NET). UUIDs v1, v6, and v7 expose timestamps and should not be used as secrets — they are identifiers, not credentials.

Why does my UUID look like 00000000-0000-0000-0000-000000000000 and what is the nil UUID?

The all-zeros UUID is the nil UUID (RFC 4122 section 4.1.7), reserved as a sentinel meaning "absent" or "not yet assigned." It is the UUID equivalent of NULL, useful in databases where the column is NOT NULL but the row has not yet been assigned a real identifier. Its counterpart, the max UUID (all-Fs, ffffffff-ffff-ffff-ffff-ffffffffffff) was formalized in RFC 9562 as the universal upper bound — useful for range queries and as the LSN equivalent in append-only logs. Both are legal UUIDs but never appear as random output: the chance of generating either by accident is 1 in 2^122, effectively zero. If you see the nil UUID in production data, your code most likely failed to initialize the value before insert — add a defensive check and trace back to the constructor.

Key Features

• Generate UUID v1 (timestamp-based)
• Generate UUID v4 (random - most common)
• Generate UUID v5 (name-based SHA-1)
• Nil UUID (all zeros)
• Bulk generation (1-100 UUIDs at once)
• Uppercase/lowercase formatting
• Include/exclude hyphens
• Include/exclude braces { }
• Copy all UUIDs to clipboard
• Download as text file
• 100% client-side - cryptographically secure random
• No server communication
• Works offline
• Dark mode support
• Mobile-friendly