UUID Generator: The Complete Guide to UUID v4, v7 & GUIDs

A UUID (Universally Unique Identifier) is a 128-bit value, almost always written as 32 hexadecimal digits split into five groups by hyphens: 8-4-4-4-12, for example 7c9e6679-7425-40de-944b-e07fc1f90ae7. That 36-character string — 32 hex digits plus 4 hyphens — is the canonical form defined by RFC 9562, the current specification for UUIDs, published in May 2024 to obsolete the older RFC 4122.

The reason UUIDs exist at all is coordination — or rather, the lack of it. An auto-incrementing integer primary key needs a single authority (the database) handing out the next number in sequence, which means every writer has to ask that authority first. A UUID needs no such thing: any machine, any process, any offline client can compute one on its own, with no round trip and effectively no chance that two of them collide. That property is what makes a random UUID generatoruseful for distributed systems, offline-first apps, and any case where an ID has to exist before it's ever written to a central store.

Not every bit in a UUID is random or meaningful data. Two fixed positions are reserved by the spec itself: the first character of the third group is always the version (4 for v4, 7 for v7, and so on), and the first character of the fourth group is the variant, which for any RFC 9562 UUID is always 8, 9, a, or b. That leaves 122 bits free for a version 4 UUID to fill with pure randomness, or — for version 7 — a Unix millisecond timestamp plus a smaller random suffix. RFC 9562 formally defines eight UUID versions (v1 through v8), but for everyday application development, only two of them come up in practice: v4 and v7.

This is the question that actually matters once you understand the format: should this system reach for a UUID v4 generator or a UUID v7 generator? The honest answer is "it depends on what the ID is for," and the two versions trade off in a specific, learnable way.

The practical rule: default to v4 when you have no particular reason to sort by ID, or when revealing roughly when a row was created is genuinely undesirable. Reach for v7for a new database primary key, because a v4 key scatters every insert to a random page in a clustered B-tree index — forcing random writes and hurting cache locality as the table grows — while a v7 key's timestamp prefix keeps new rows clustered near the end of the index, the way an auto-incrementing integer already does, without giving up decentralized, coordination-free generation.

As for UUID vs. GUID— this isn't actually two formats. GUID (Globally Unique Identifier) is Microsoft's name for the exact same 128-bit layout that RFC 9562 defines. The confusion mostly traces back to the .NET Guid type, which historically defaulted to version 4 generation and to a braced string format like {7c9e6679-...} via Guid.ToString("B"). Strip the braces and normalize to the standard hyphenated form, and a .NET GUID and a UUID produced by any RFC-9562-compliant generator are interchangeable.

A UUID means something slightly different depending on where it sits in a system. A quick tour of who reaches for one and why:

• Backend & database engineers— v7 for new table primary keys, where index locality at scale matters; v4 for anything that shouldn't leak an approximate creation time.
• Frontend developers — a v4 UUID makes a stable React keyprop for a list item that doesn't have a natural ID yet, or an idempotency key attached to a request so a retried submit doesn't create a duplicate on the server.
• QA & test engineers — a bulk UUID generator producing dozens of distinct, well-formed IDs at once is exactly what test fixtures need: values that only have to be unique, not meaningful, exported straight into a JSON or CSV fixture file.
• DevOps & platform engineers — UUIDs name resources, correlation IDs, and request IDs in logs and traces, where a short, collision-free identifier beats a hand-picked name for anything generated automatically at scale.
• Security-adjacent uses, with a caution— UUIDs turn up constantly as session IDs and token-like values because they're easy to generate and look opaque. Treat that use carefully: a UUID is an identifier, not a secret, and the distinction matters more than it looks — see the FAQ below.

A browser tool is the right call for a one-off value or a bulk export. The moment UUID generation needs to run inside an application, a script, or a migration, it belongs in code — which is usually what someone searching uuid generator python or uuid generator javascript is actually after.

Python: the uuid module

import uuid

# Version 4 — cryptographically random
print(uuid.uuid4())
# e.g. 7c9e6679-7425-40de-944b-e07fc1f90ae7

# Version 1 — timestamp + the generating machine's MAC address.
# Sortable, but leaks hardware identity — v7 is the modern replacement
# for most of what v1 used to be reached for.
print(uuid.uuid1())

Python added native v7 support in 3.14 (uuid.uuid7(), alongside uuid6() and uuid8()). On the many codebases still running 3.11-3.13, a v7 value has to come from a small third-party package instead, or from letting the database generate it on insert.

JavaScript: crypto.randomUUID()

// Available in browsers and Node.js — no library needed.
// Generates a version 4 UUID using a CSPRNG under the hood.
const id = crypto.randomUUID();
console.log(id); // e.g. 3fa85f64-5717-4562-b3fc-2c963f66afa6

crypto.randomUUID() is only exposed in a secure context — HTTPS or localhost— because it's part of the Web Crypto API. It always produces version 4; v7 support isn't built into the browser API yet, so a v7 value in JavaScript comes from a small userspace implementation that combines Date.now() with crypto.getRandomValues() for the random suffix.

SQL: generating a UUID at the database

-- v4, built into core Postgres since version 13, no extension needed:
SELECT gen_random_uuid();

-- Older Postgres versions, or explicit v4 naming, need the uuid-ossp extension:
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
SELECT uuid_generate_v4();

-- v7, built into core Postgres since version 18 — no extension needed:
SELECT uuidv7();

-- A typical v7 primary key column:
CREATE TABLE items (
  id uuid PRIMARY KEY DEFAULT uuidv7(),
  name text NOT NULL
);

Letting Postgres generate the value with a column default means every insert gets a UUID with no application-side code required — useful for seed scripts, and for keeping ID generation consistent regardless of which service is writing the row. On Postgres versions older than 18, generate a v7 value in application code instead and pass it in explicitly, since uuidv7()isn't available yet.

The nil UUID (and the newer max UUID)

00000000-0000-0000-0000-000000000000 — all 128 bits zero — is the nil UUID, reserved by the spec as a sentinel meaning "no UUID" or "not set," the UUID equivalent of a null pointer. It's a valid, well-formed UUID string that intentionally carries no version or variant information. RFC 9562 also introduced a companion value, the max UUID — ffffffff-ffff-ffff-ffff-ffffffffffff, all bits set to one — useful as an explicit upper-bound sentinel in range queries, the way nil serves as a lower bound.

Is a UUID always unique?

Not by mathematical guarantee, but close enough that the exception is never the practical explanation for a duplicate. A version 4 UUID has 122 bits of real randomness. Using the birthday-bound approximation, reaching 50% odds of even one collision requires generating roughly 2.3 × 10¹⁸v4 UUIDs — that's a billion generated every single second, for about 73 years straight. If a duplicate shows up in real application data, the far more likely explanation is a code bug: an ID generated once and reused across rows, hoisted out of a loop, or hardcoded as a placeholder — not an actual collision.

Why v7 fixes index fragmentation

This is exactly why Postgres added a native uuidv7()function in version 18, and why several ORMs added v7 helpers of their own once RFC 9562 stabilized — and why teams migrating an existing v4 schema to v7 are usually doing it for one specific reason: fixing index bloat that got worse as the table grew, not because v4 was ever "wrong."

Every option here is free and requires no account, which is table stakes for this kind of tool. The real gap, across the field, is depth: most UUID generators treat v7 as an afterthought or skip it entirely, even though it's become the default recommendation for new database keys. GenKitLab's UUID generator runs entirely client-side — generation uses crypto.getRandomValues(), never Math.random(), and nothing you generate is transmitted or logged anywhere.

UUIDs are one piece of a larger identifier toolkit. A few tools that pair naturally with generating one:

• ULID Generator — a different sortable-identifier format that encodes the same 48-bit millisecond timestamp as v7, but as its own 26-character Crockford base32 string rather than a UUID; useful for comparing the two side by side before choosing one for a schema.
• Unix Timestamp Converter — decode any epoch value to a date in a specific timezone, the same operation this article's v7 worked example runs internally on the timestamp embedded in a v7 UUID.
• JSON Formatter & Validator — format and validate the JSON array a bulk UUID export produces, or paste it into a fixture file with confidence it parses cleanly.

See the full Database tools category for schema and query utilities that go with identifier generation.

1. Internet Engineering Task Force. RFC 9562: Universally Unique IDentifiers (UUIDs). Obsoletes RFC 4122. May 2024.
2. Python Software Foundation. "uuid — UUID objects according to RFC 4122/9562." Python 3 documentation.
3. Mozilla Developer Network. "Crypto: randomUUID() method." MDN Web Docs.
4. The PostgreSQL Global Development Group. "UUID Functions." PostgreSQL Documentation.