UUID generator for version 4 UUIDs.

A UUID (universally unique identifier) is a 128-bit value that systems can create independently, with no central counter, and still expect to be unique. The current specification is RFC 9562, published in 2024, which replaced RFC 4122.

The text form is 32 hexadecimal digits in five groups separated by hyphens, 8-4-4-4-12, for 36 characters in total. RFC 9562 asks systems to output lowercase and to accept any case on input. GUID (globally unique identifier) is Microsoft's name for the same format; Windows tools often print it in uppercase and wrap it in braces.

Six of the 128 bits describe the UUID itself. The first hex digit of the third group is the version, so every v4 UUID has a 4 there. The first hex digit of the fourth group holds the variant and is always 8, 9, a or b. The remaining 122 bits are random.

This page calls crypto.randomUUID, which every current browser provides in secure (HTTPS) contexts. It draws from the operating system's cryptographically secure random number generator, the same source used for encryption keys. Older snippets built on Math.random are not suitable: Math.random is not designed to be unpredictable, and weak generators are where real-world duplicates come from. Because the version and variant digits are fixed, you can recognise a v4 UUID at a glance and check one with a simple pattern, as in the examples below.

Version 1 combines a timestamp with a node ID that was traditionally the machine's MAC address, which leaks when and where it was created. Versions 3 and 5 hash a namespace and a name (MD5 and SHA-1), so the same input always gives the same UUID, which is useful for deterministic IDs such as one per URL. Version 4 is random.

RFC 9562 added versions 6, 7 and 8. Version 7 starts with a 48-bit Unix timestamp in milliseconds followed by random bits, so values sort by creation time. That makes it the usual choice for new database keys, while v4 remains the simplest choice when you want IDs that reveal nothing about timing. Version 8 is reserved for custom layouts. The spec also defines the Nil UUID (all zeros) and the Max UUID (all f).

This generator produces version 4 only.

In theory yes, in practice no. With 122 random bits there are about 5.3 x 10^36 possible v4 UUIDs. By the birthday bound, you would need roughly 2.7 x 10^18 of them before the chance of even one duplicate reached 50%. At a billion UUIDs per second, that takes about 86 years.

Duplicates in real systems come from bugs, not from the maths: a broken or seeded random generator, a cloned virtual machine reusing state, or an ID copied between records. A unique constraint in the database is still a sensible safety net.

UUIDs let clients, services and offline devices create IDs without asking the database, which helps with database sharding, merging data and retries. Offline-first apps benefit too: a phone can create a record with its final ID while disconnected and sync it later without renumbering anything. They also stop public URLs revealing how many orders or users you have.

The cost is size and locality. Store them in a native type, such as PostgreSQL's uuid (16 bytes) or BINARY(16) in MySQL, never as 36-character text. Random v4 keys insert at random positions in a B-tree index, which can mean more page splits and cache misses on write-heavy tables; time-ordered v7 keys append near the end instead. Our Postgres indexing guide covers the trade-offs.

PostgreSQL has gen_random_uuid() built in for v4, and recent releases (PostgreSQL 18 and later) add uuidv7(). MySQL's UUID() function returns version 1 values. For a wider comparison of the two databases, see PostgreSQL vs MySQL.

The canonical form is 36 lowercase characters with hyphens. You will also meet the 32-character form without hyphens, the Microsoft form in braces such as {3F2B8C1E-9D4A-4F7E-8B21-6C0D5E9A1F47}, and the URN form urn:uuid:3f2b8c1e-9d4a-4f7e-8b21-6c0d5e9a1f47 for places that need a URI. All of them describe the same 128 bits, so normalise to one form before you compare or store values.

In binary a UUID is 16 bytes. Most systems store them in the order they appear in the text, but Microsoft's GUID structure stores the first three groups in little-endian order. The same GUID can therefore produce different byte sequences in .NET and in a column written by another language. If IDs look scrambled after crossing between systems, check byte order first.

Use the Uppercase and Hyphens options here to match the text form your system expects. Braces or a urn:uuid: prefix can be added afterwards with a quick find-and-replace.

Good uses include public resource IDs, correlation IDs for tracing a request across services, file names for uploads, and idempotency keys that let an API safely ignore a retried payment or order.

RFC 9562 warns not to assume UUIDs are hard to guess, so do not use them as passwords, session tokens or password-reset links on their own. Use a purpose-built random token for those, or a long random string from the password generator.