UUID Generator

A UUID (Universally Unique Identifier) is a 128-bit label defined in RFC 4122. Its defining property is that it can be generated independently on any device, at any time, without coordination, and remain practically unique across all systems that use it.

UUIDs come in several versions. v1 encodes the current time and the generating machine's MAC address. v3 and v5 are deterministic — they hash a namespace and a name to produce a reproducible UUID. v4 is fully random. v7 (RFC 9562) embeds a millisecond timestamp for sort order. v4 is the most widely used for general-purpose identifiers.

The standard text representation is 32 hex digits in five hyphen-separated groups: 8-4-4-4-12. The total length is always 36 characters including hyphens.

UUID v4 uses 122 bits of random data. The remaining 6 bits encode the version (4) and the RFC 4122 variant, and are fixed. This tool generates UUIDs using crypto.randomUUID(), which is backed by the operating system's cryptographically secure random number generator — the same source used for TLS key generation.

The probability of two v4 UUIDs colliding is approximately 1 in 5.3 × 10³⁶ per pair. To put that concretely: generating 1 billion UUIDs per second for 100 years, the probability of any collision occurring remains below 0.000000006%. For practical purposes they are unique — but they are not mathematically guaranteed unique, and no implementation can make that guarantee.

If your application truly cannot tolerate even an astronomically unlikely collision (for example, cryptographic key material), UUID v4 is not the right primitive. For record identifiers, session tokens, file names, and correlation IDs, it is the appropriate choice.

A UUID v4 is 32 hexadecimal digits (128 bits) in five groups separated by hyphens: 8-4-4-4-12. The segment boundaries are historical convention from earlier versions; in v4 they carry no structural meaning.

Two positions are not random. The 13th character (first digit of the third group) is always 4 — the version. The 17th character (first digit of the fourth group) is always 8, 9, a, or b — the variant. These two markers allow validators and parsers to confirm a string is a well-formed UUID v4 without any other context.

UUIDs are case-insensitive. f47ac10b-... and F47AC10B-... represent the same value. Most databases and languages normalize to lowercase, but parsers accept both.

Databases: UUIDs work as primary keys in PostgreSQL (uuid type), MySQL (CHAR(36) or BINARY(16)), and SQLite (TEXT). The main advantage is that IDs can be assigned in application code before the row is written, removing a database round-trip and enabling offline-first or multi-source insert patterns.

APIs: UUIDs in REST endpoints (/orders/f47ac10b-58cc-4372-a567-0e02b2c3d479) avoid exposing sequential counters that reveal record volume. They also prevent enumeration attacks where an attacker increments an integer ID to access records they should not see.

Distributed systems: when multiple services, regions, or clients create records independently and merge them later, sequential IDs conflict. UUIDs eliminate the coordination step — each service generates its own IDs with negligible collision risk.

Test fixtures: UUIDs are useful for seeding test databases with predictable-looking but non-sequential IDs, or for generating unique filenames for uploaded assets in test runs without cleanup dependencies.

Sequential integer IDs (SERIAL, AUTO_INCREMENT, SEQUENCE) sort naturally, are compact (4–8 bytes vs 16), and index efficiently in B-trees because new rows always append to the right end of the index.

UUID v4 inserts into random positions in a B-tree index, causing page splits as the table grows. On tables with millions of rows and high insert rates, this produces measurable write amplification and index bloat. For read-heavy workloads or moderate insert rates, the effect is negligible.

UUID v4 exposes no information about insertion order, record count, or timing — a property that is useful for security but inconvenient when you need "show me the most recently created 10 records" without a separate timestamp column.

If you need both random IDs and sort order, UUID v7 or ULID are designed for this: they embed a timestamp prefix so generated values sort by creation time while remaining globally unique without coordination.

Set the count and click Generate. All UUIDs are generated in one batch using Array.from({ length: n }, () => crypto.randomUUID()). Copy individual values with the row button, or use Copy All to get the full list.

Bulk generation is useful for seeding a test database with unique primary keys before writing the application code, pre-generating a set of asset filenames for a batch upload, or producing a list of one-time identifiers for a test fixture file.

Every UUID in a batch is independently random — they share no sequential or time-based relationship with each other.

RFC 4122 defines five UUID versions, each with a different generation strategy. Picking the right one depends on whether you need randomness, time ordering, or deterministic reproducibility.

UUID v1 is generated from the current timestamp plus the host machine's MAC address. It guarantees uniqueness across machines without coordination, but it leaks the generating host's hardware identifier and the moment of generation — both privacy concerns for many applications.

UUID v3 and v5 are deterministic: they hash a namespace UUID together with a name string (v3 uses MD5, v5 uses SHA-1) to produce the same UUID every time the same inputs are given. Use v5 when you want stable identifiers derived from existing data — for example, deriving a content UUID from a URL.

UUID v4 is fully random (122 bits of entropy). It is the default choice when you need an opaque, unguessable identifier with no information leakage. Most modern applications, APIs, and database primary keys use v4.

UUID v7 (RFC 9562, 2024) embeds a millisecond Unix timestamp in the high bits with random data filling the rest. The result sorts lexicographically by creation time while remaining globally unique without coordination — the best of both worlds for database primary keys at high insert rates.

Every modern runtime ships a built-in UUID v4 generator backed by the operating system's cryptographic RNG. The snippets below produce a fresh random UUID in each environment so you can drop them straight into application code without pulling in a dependency for the simple case.

JavaScript: crypto.randomUUID() is available in all modern browsers and in Node.js 14.17+. It returns a v4 UUID as a lowercase string and uses the same secure random source as TLS key generation. No npm package required.

Python: the uuid module is in the standard library — no pip install needed. uuid.uuid4() returns a UUID object; wrap it with str() to get the canonical hyphenated form. For a deterministic v5 UUID, use uuid.uuid5(namespace, name).

Go: the standard library does not include UUID generation, but github.com/google/uuid is the de-facto package. uuid.New() returns a v4 UUID, and .String() formats it as the canonical 36-character form.

A UUID is 128 bits (16 bytes), rendered as 32 hexadecimal characters in five hyphen-separated groups: 8-4-4-4-12. The total length is always 36 characters, including the four hyphens. Lowercase is conventional but parsers accept either case.

The five groups originate from earlier UUID versions where each segment encoded a specific field — time-low, time-mid, time-high-and-version, clock-sequence, and node. In v4 the segment boundaries no longer carry semantic meaning, but the version and variant nibbles in fixed positions still identify which generation strategy produced the value.

Two characters are not random in v4: the 13th character (M in xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx) is the version digit and is always 4 for v4, 7 for v7, and so on. The 17th character (N) is the variant nibble and is always one of 8, 9, a, or b for RFC 4122 UUIDs.

Two special UUIDs are reserved as sentinels. The Nil UUID (all zeros: 00000000-0000-0000-0000-000000000000) represents "no value" or an uninitialised reference, similar to NULL in SQL. The Max UUID (all ones: ffffffff-ffff-ffff-ffff-ffffffffffff), formalised in RFC 9562, is the lexicographic upper bound and is sometimes used as a sentinel for "end of range" in sorted indexes.

Database primary keys: UUIDs let application code assign IDs before writing rows, removing a database round-trip and enabling offline-first writes, multi-region inserts, and client-generated IDs that survive network failures. PostgreSQL has a native uuid type; MySQL stores them as BINARY(16) for efficiency or CHAR(36) for readability.

Distributed system identifiers: when independent services or shards must produce unique IDs without coordination, UUIDs eliminate the need for a central sequence generator. Two services on different continents can mint IDs simultaneously with no risk of collision.

File and object names: cloud storage paths like s3://bucket/uploads/9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d.jpg use UUIDs to avoid filename collisions across simultaneous uploads, prevent guessing of neighbouring files, and decouple storage paths from user-facing names.

Session tokens and correlation IDs: a UUID v4 in a Set-Cookie header or an X-Request-ID HTTP header is unguessable, easy to log, and useful for tracing a single request across microservices. For session security tokens with long lifetimes, prefer a longer random token (32+ bytes); UUID v4's 122 bits of entropy are sufficient for most short-lived correlation purposes.

Idempotency keys: APIs that accept POST requests (payments, order creation) often require a client-supplied idempotency key — a UUID is the standard choice. The server stores the key with the response and returns the cached response if the same key is replayed, making retries safe across network failures.