UUID Generator — Generate UUID v4 Online

Generate cryptographically random UUID v4 identifiers instantly. Choose quantity and format, copy with one click — no server, no signup, runs entirely in your browser.

What is a UUID?

A UUID (Universally Unique Identifier), also known as a GUID (Globally Unique Identifier), is a 128-bit identifier that is guaranteed to be unique across space and time. A standard UUID looks like this: 550e8400-e29b-41d4-a716-446655440000. It consists of 32 hexadecimal digits displayed in five groups separated by hyphens, in the form 8-4-4-4-12.

UUIDs are defined by RFC 4122 and are one of the most widely used standards for unique identification in software systems worldwide.

What is UUID v4?

UUID version 4 is the most commonly used variant. It is generated using a cryptographically secure random number generator, making collisions statistically impossible. The "4" in position 13 of the UUID indicates the version, and the variant bits in position 17 are set to indicate RFC 4122 compliance.

This tool uses crypto.randomUUID() — the browser's native, cryptographically secure UUID generator — with a fallback to crypto.getRandomValues() for maximum security and compatibility.

Common Use Cases for UUID

Database Primary Keys

UUIDs make excellent primary keys in distributed databases because they can be generated independently on any node without coordination. Unlike auto-increment integers, UUID-based IDs do not expose record counts, cannot be enumerated, and remain unique when merging data from multiple databases.

API Resources and REST Endpoints

Using UUIDs as resource identifiers in REST APIs prevents sequential ID enumeration attacks. Endpoints like /api/users/550e8400-e29b-41d4-a716-446655440000 reveal nothing about the total number of users.

Session and Token Identifiers

UUIDs are widely used as session tokens, request correlation IDs, idempotency keys, and transaction references. Their unpredictability and uniqueness make them ideal for tracking requests across distributed microservices.

File Names and Content Addressing

When storing uploaded files, using UUID-based file names eliminates collisions and prevents filename guessing. This is standard practice in cloud storage systems like AWS S3 and Azure Blob Storage.

UUID Format Options

Standard (lowercase): 550e8400-e29b-41d4-a716-446655440000 — the canonical RFC 4122 format, most interoperable.

Uppercase: 550E8400-E29B-41D4-A716-446655440000 — some legacy systems and Microsoft APIs use uppercase GUIDs.

No hyphens: 550e8400e29b41d4a716446655440000 — compact form used in some databases and APIs that don't support hyphens.

With braces: {550e8400-e29b-41d4-a716-446655440000} — the Microsoft GUID notation used in Windows APIs and COM.

Examples by Format

Standard (RFC 4122)

550e8400-e29b-41d4-a716-446655440000
6ba7b810-9dad-11d1-80b4-00c04fd430c8
f47ac10b-58cc-4372-a567-0e02b2c3d479

Common Usage Patterns

-- SQL
INSERT INTO users (id) VALUES ('550e8400-...');

// JavaScript
const id = crypto.randomUUID();

# Python
import uuid; str(uuid.uuid4())

UUID v4 is random. UUID v7 is sortable. Most code uses the wrong one.

Editor’s note — by Amine H., last reviewed 27 May 2026.

A UUID is 128 bits of identifier, formatted as 32 hex digits in five groups: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx. The character at position M encodes the version, the character at N encodes the variant. Most online generators give you v4 (random) by default — including, currently, this one. For 2026 database design, v4 is rarely the right choice. Here is what each version does and when to use it.

v1 — timestamp plus MAC address (don’t use)

Encodes a 60-bit timestamp and the network MAC address of the machine that generated the UUID. Sortable by time, technically. Leaks the MAC address of your server — useful for an attacker mapping your infrastructure. There are mitigations (random MAC, hashed MAC) but at that point you have reinvented v7. Skip.

v3 and v5 — deterministic name-based

MD5 (v3) or SHA-1 (v5) hash of a namespace UUID concatenated with a name. The same namespace+name always produces the same UUID. Useful when you need a stable ID derived from input you control (e.g., a deterministic ID from a file path, a URL, or an email address). Prefer v5 over v3 since MD5 is deprecated for security — though for name-based UUIDs the threat model is collision-by-accident, not adversarial, so v3 is workable.

v4 — 122 bits of pure random

The default everywhere. Twelve hex characters of metadata (version + variant), 30 hex characters of random. Probability of collision: negligible for any practical scale. Cryptographically random when generated with the right RNG. Excellent for stateless tokens, public-facing IDs where you do not want enumeration, and any case where you do not care about insertion order.

v6 — v1 reordered for sortability (niche)

Takes the timestamp fields of v1, reorders them most-significant-first so the UUID sorts lexicographically by creation time, but still includes the MAC. Largely a transitional spec. If you want time-sortable UUIDs, jump straight to v7.

v7 — what you actually want for database primary keys

Published in RFC 9562 (2024). First 48 bits are a Unix-millisecond timestamp, remaining bits are random. Lexicographically sortable, monotonic within a millisecond, no MAC leak. Designed specifically to be a good primary key in B-tree indexes. This is what you want in PostgreSQL, MySQL, or any database where insertion order matters for index locality.

Why v4 is bad as a database primary key

Pure-random UUIDs as a clustered or default index destroy insertion locality. Each new row lands in a random page of the index, causing random page splits in a B-tree, doubling or tripling write amplification on busy tables. Independent benchmarks (PlanetScale, Supabase, AWS RDS) consistently show 20–50% throughput penalty for v4 vs sequential or time-ordered IDs at scale. v7 keeps the benefits of UUIDs (no central authority, no enumeration risk) while restoring index locality.

ULID and the related crowd

ULID (Universally Unique Lexicographically Sortable Identifier) pre-dates v7 by several years and solves the same problem with Crockford Base32 encoding (26 characters instead of 36, no hyphens). NanoID, KSUID, Snowflake all live in this same space. They are all reasonable; v7 has the advantage of being a UUID and therefore plug-compatible with code expecting one.

Takeaway: For new database designs in 2026: use UUID v7 if your stack supports it, ULID if you prefer the shorter form, v4 only when you specifically want unsortable randomness (public-facing tokens, anti-enumeration). The generator on this page outputs v4 by default because it is what people search for — but if you are designing a primary key for a table that will grow, v7 is the better default. The 20–50% write-throughput penalty of v4-as-PK is real and shows up in production benchmarks, not just theory.

Sources: RFC 9562 (UUIDs, 2024 — supersedes RFC 4122) · ULID specification · Buildkite: v4 to v7 migration write-up.

Frequently Asked Questions

UUID v4 has 122 random bits, giving approximately 5.3 × 10³⁶ possible values. The probability of generating two identical UUIDs is astronomically small — roughly 1 in 5.3 undecillion. In practice, UUID collisions are not a concern: you would need to generate over a billion UUIDs per second for 85 years to have just a 50% chance of one collision.

UUID v1 is generated from the current timestamp and the generating machine's MAC address. This makes v1 UUIDs time-sortable and traceable back to the generating machine — a potential privacy concern. UUID v4 is fully random and reveals no information about when or where it was generated, which makes it the preferred choice for most modern applications.

GUID (Globally Unique Identifier) is Microsoft's implementation of the UUID standard. In practice, a GUID and a UUID v4 are interchangeable — they use the same 128-bit format and the same RFC 4122 specification. The terms are often used synonymously in .NET, SQL Server, and Windows development.

UUIDs as primary keys have pros and cons. Pros: globally unique (great for distributed systems and data merging), non-guessable, no coordination needed between nodes. Cons: larger storage size than integers (16 bytes vs 4-8 bytes), random UUID v4 keys cause index fragmentation in B-tree indexes. If you need sortable UUIDs for index performance, consider UUID v7 (time-ordered) which avoids fragmentation while remaining unique.

No. UUID comparisons are case-insensitive by specification. 550e8400-e29b-41d4-a716-446655440000 and 550E8400-E29B-41D4-A716-446655440000 represent the same UUID. Most databases and programming languages normalize UUIDs to lowercase internally.

Yes. This tool uses crypto.randomUUID() when available (all modern browsers) or crypto.getRandomValues() as a fallback — both are cryptographically secure APIs provided by the browser's native crypto module. The random values are not predictable and are suitable for security-sensitive use cases like session tokens.

A nil UUID is a special UUID where all 128 bits are set to zero: 00000000-0000-0000-0000-000000000000. It is used as a placeholder or null value in contexts where a UUID is required but no real identifier exists. It is analogous to null in many programming contexts.

No. All UUID generation happens entirely in your browser using the native Web Crypto API. No data is sent to any server. This tool works completely offline once the page is loaded.

Related Tools