Generate UUIDs and GUIDs instantly: Paste this tool into your workflow and create cryptographically secure, collision-resistant identifiers for databases, distributed systems, API payloads, test data, and file naming — directly in your browser, with zero server contact.

What Is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit label standardized by RFC 9562 (published April 2024, superseding the original RFC 4122 from 2005). Its defining property is that it can be generated independently on any machine, at any time, without any central coordinating authority — and still be, for all practical purposes, globally unique.

The standard text representation is 32 hexadecimal digits split into five groups by hyphens:

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

Where M encodes the version (the algorithm used to generate the UUID) and N encodes the variant (the bit layout standard — always 8, 9, a, or b for RFC 9562 UUIDs).

A concrete example of a UUID v4:

550e8400-e29b-41d4-a716-446655440000

That is 32 hex characters = 128 bits of data. The hyphen positions are purely cosmetic and carry no information — they are stripped when UUIDs are stored in binary or compact form.

How Unique Is “Universally Unique”?

UUID v4 uses 122 bits of randomness (6 bits are reserved for version and variant metadata). To put collision risk in perspective: if you generated 1 billion UUIDs per second, you would need to sustain that rate for approximately 85 years before reaching a 50% probability of a single collision. For any real system, the collision probability is functionally zero.

UUID vs GUID — Are They the Same Thing?

Yes, for modern development purposes, UUID and GUID are the same thing.

GUID (Globally Unique Identifier) is Microsoft’s term, introduced with COM/DCOM in the 1990s. GUIDs follow the same RFC 9562 layout and 128-bit size. The historical difference was a byte-order quirk in how Microsoft serialized certain fields in binary — but in string form (the xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx format), a UUID and a GUID are identical and interchangeable.

In practice: the Windows ecosystem and .NET tend to say GUID, while Linux, macOS, web APIs, and databases tend to say UUID. Both refer to the same standard.

All UUID Versions Explained

The version number does not mean “newer is better.” It identifies the algorithm used to create the UUID. Each version solves a different problem.

Version	Algorithm	Sortable	Use Case
v1	Timestamp + MAC address	Partially	Legacy systems only
v2	DCE Security (POSIX UID/GID)	No	Obsolete, avoid
v3	MD5 namespace hash	No	Deterministic IDs (MD5 broken, prefer v5)
v4	Random	No	General purpose — the safe default
v5	SHA-1 namespace hash	No	Deterministic IDs from a name + namespace
v6	Reordered timestamp + random	Yes	Migration path from v1
v7	Unix timestamp + random	Yes	Database primary keys, modern systems

UUID v1 — Timestamp and MAC Address

v1 encodes the current timestamp (in 100-nanosecond intervals since October 1582) plus the MAC address of the generating machine. This gives partial time-ordering but leaks both the machine identity and creation time in the UUID itself. Avoid v1 in any public-facing API or system where privacy matters.

UUID v2 — DCE Security

v2 is a variant of v1 that replaces part of the timestamp with a POSIX UID, GID, or domain identifier. It was designed for Distributed Computing Environments (DCE) in the early 1990s and is effectively obsolete. You are unlikely to encounter v2 outside of legacy enterprise infrastructure.

UUID v3 — MD5 Namespace Hash

v3 generates a deterministic UUID by hashing a namespace UUID and a name together using MD5. Given the same namespace and name, v3 always produces the same UUID. This is useful when you need a stable, reproducible identifier for a known value — but MD5 is cryptographically broken. Use v5 instead for all new work.

UUID v4 — Pure Random (The General-Purpose Default)

v4 is generated from 122 bits of cryptographically secure random data. No timestamp, no MAC address, no metadata — just randomness. It is:

• Simple to generate in every language and platform
• Private — reveals nothing about when or where it was created
• Safe for tokens, session IDs, and public-facing identifiers
• Universally supported in every database, framework, and API

UUID v4 is the right choice for 95% of use cases. If you just need a unique ID and database index performance is not a concern, use v4.

UUID v5 — SHA-1 Namespace Hash

v5 works identically to v3 but uses SHA-1 instead of MD5. Given the same namespace and name, it always produces the same UUID. Use v5 when you need to generate a reproducible, collision-resistant identifier from a known input — for example, a stable UUID for a given URL, email address, or product SKU, derived from a well-known namespace.

UUID v6 — Reordered Timestamp

v6 is a reorganized variant of v1 that places the timestamp in big-endian order so that v6 UUIDs sort chronologically. It exists primarily as a migration bridge from v1 to v7 for systems that already use v1. For new systems, go straight to v7.

UUID v7 — The Modern Default for Database Keys

UUID v7 was formalized in RFC 9562 (2024) and is rapidly becoming the recommended default for new projects that use UUIDs as database primary keys.

v7 embeds a 48-bit Unix timestamp in milliseconds in the most-significant bits, followed by random data. Because the timestamp is at the front, v7 UUIDs are lexicographically sortable — they sort in creation order as both strings and binary values.

019047b4-1c5e-7000-b703-24c3f6a5c849
│           │         │
└─ 48-bit Unix ms timestamp  └─ random bits

This ordering property has major implications for database performance.

UUID v4 vs UUID v7 — Which Should You Use?

	UUID v4	UUID v7
Generation	Pure random	Timestamp + random
Sortable	No	Yes (by creation time)
Timestamp embedded	No	Yes (48-bit ms precision)
Privacy	High — reveals nothing	Leaks creation time
DB index performance	Poor at scale	Excellent
Browser support	crypto.randomUUID()	Manual construction
RFC	RFC 9562	RFC 9562

Use UUID v4 when:

• You need a public-facing token, session ID, or opaque reference
• Hiding the creation time is important (security tokens, invite links)
• You are working in a context where database index performance is not a bottleneck

Use UUID v7 when:

• The UUID will be a database primary key
• You want records to sort naturally by creation time without a separate created_at column
• You are building a distributed system that generates IDs across many nodes

UUID as a Database Primary Key — The Performance Guide

This is where UUID version choice has the most visible engineering impact.

Why UUID v4 Hurts Database Performance

Relational databases like MySQL InnoDB and PostgreSQL use B-tree indexes for primary keys. B-trees are optimized for sequential insertion — each new row goes near the end of the last written page. This pattern fills pages efficiently and minimizes disk I/O.

UUID v4 is random. Each new UUID inserts into a random position in the B-tree. This causes:

• Page splits: The engine must frequently split full pages to make room for random inserts, fragmenting the index
• Cache eviction: Random access means the engine must keep loading old pages from disk rather than working at the hot end of the tree
• Wasted space: Page utilization can drop to 50% due to fragmentation
• Slower range queries: No temporal locality — rows created close in time are scattered across the index

At low row counts this is invisible. At tens of millions of rows with sustained write throughput, random UUID primary keys cause measurable performance degradation.

Why UUID v7 Solves This

v7’s timestamp prefix means each new UUID is greater than all previously generated UUIDs (within the same millisecond, a sequence counter or random bits maintain order). The B-tree receives append-only inserts at the rightmost leaf — the same efficient pattern as an auto-incrementing integer.

Benchmarks at scale show up to 400% faster write performance with ordered UUIDs compared to random v4, with proportionally lower index fragmentation.

Binary Storage

Whether you use v4 or v7, storing UUIDs as CHAR(36) strings wastes space. Use BINARY(16) or your database’s native UUID type:

• PostgreSQL: Built-in UUID type (stores as 16 bytes internally)
• MySQL: BINARY(16) or the UUID_TO_BIN() / BIN_TO_UUID() functions with the swap_flag=1 argument to move the timestamp bits to the front (equivalent to v6 ordering)
• MongoDB: Native UUID BSON subtype

How to Generate UUIDs in Code

JavaScript / Node.js

// Node.js 14.17+ and all modern browsers
const id = crypto.randomUUID(); // UUID v4

// Node.js 19+ / third-party for v7
import { v7 as uuidv7 } from 'uuid';
const id = uuidv7();

Python

import uuid

id_v4 = str(uuid.uuid4())
id_v5 = str(uuid.uuid5(uuid.NAMESPACE_URL, 'https://example.com'))

Java

import java.util.UUID;

UUID id = UUID.randomUUID(); // v4
String idStr = id.toString();

C# / .NET

Guid id = Guid.NewGuid(); // v4
string idStr = id.ToString(); // "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

PostgreSQL

-- Native UUID v4 (PostgreSQL 13+)
SELECT gen_random_uuid();

-- UUID v7 via pg_uuidv7 extension
SELECT uuid_generate_v7();

Go

import "github.com/google/uuid"

id := uuid.New()         // v4
idStr := id.String()

UUID Format and Structure Reference

550e8400 - e29b - 41d4 - a716 - 446655440000
│          │      │      │      │
│          │      │      │      └── Node (48 bits)
│          │      │      └───────── Clock sequence (14 bits) + Variant (2 bits)
│          │      └──────────────── Version (4 bits) + Time mid (12 bits)
│          └─────────────────────── Time mid (16 bits)
└────────────────────────────────── Time low (32 bits)

Version digit (M): The 13th character. 4 = random, 7 = timestamp-prefixed.

Variant bits (N): The 17th character. Always 8, 9, a, or b for RFC 9562 UUIDs — these two bits identify the UUID as following the RFC 9562 layout rather than an earlier proprietary scheme.

Special UUIDs

• Nil UUID: 00000000-0000-0000-0000-000000000000 — all bits zero, used as a null/sentinel value
• Max UUID: ffffffff-ffff-ffff-ffff-ffffffffffff — all bits one, RFC 9562 defines this as a valid special-case UUID

Output Formats

The same UUID value can be represented several ways depending on what the consuming system expects:

Format	Example
Standard (hyphenated)	550e8400-e29b-41d4-a716-446655440000
Compact (no hyphens)	550e8400e29b41d4a716446655440000
Braces	{550e8400-e29b-41d4-a716-446655440000}
Uppercase	550E8400-E29B-41D4-A716-446655440000
URN	urn:uuid:550e8400-e29b-41d4-a716-446655440000

Real-World Use Cases

1. Database Primary Keys

UUIDs allow distributed systems to generate primary keys without a central sequence generator. Unlike auto-incrementing integers, UUID primary keys do not reveal the total row count or insertion order to external callers. Use UUID v7 for new tables where you control the schema.

2. Distributed System IDs — No Coordination Required

In a microservices architecture, multiple services generating records independently cannot share an auto-increment sequence without a coordinating service. Each node generates its own UUIDs and inserts them without risk of collision — even if the services have never communicated.

3. Idempotency Keys for Payment and API Operations

Payment processors like Stripe and APIs that support idempotency require a unique key per request. Sending the same idempotency key twice returns the cached result rather than executing the operation again. UUIDs are the standard format for these keys.

4. Collision-Safe File and Asset Naming

Uploaded files named by UUID cannot collide regardless of how many users upload files simultaneously. UUID-named objects in S3, GCS, or any blob store are safe to create in parallel without a locking strategy.

5. Session and Token Identifiers

UUIDs are widely used as session IDs, password-reset tokens, email verification links, and invite codes. Use v4 for these — the opaque randomness reveals no metadata about when the token was issued.

6. Deterministic IDs from Known Inputs (v5)

When you need a stable, reproducible UUID for a given input — a canonical UUID for a URL, a product SKU, or a user email — generate it with UUID v5 using a fixed namespace. The same input always produces the same UUID, making it safe to generate the ID without looking it up in a database first.

How to Use This UUID Generator

1. Enter the quantity of UUIDs you need (1 to 1000).
2. Choose the output format: standard hyphenated, compact, braces, or uppercase.
3. Click Generate UUIDs, or enable Auto Generate to create new IDs on every page load.
4. Click Copy to copy all IDs to your clipboard, or Download to save them as a .txt file.
5. To normalize existing UUIDs, paste them into the second panel. The tool validates each value and converts it to standard lowercase hyphenated format.

Data as Parameter

Pre-fill the generator count via URL:

https://www.uprek.com/en/tools/uuid-guid-generator?count=25

Pre-fill the normalizer panel with an existing UUID string:

https://www.uprek.com/en/tools/uuid-guid-generator?input=123e4567e89b42d3a456426614174000

Your Data Never Leaves Your Browser

When you use this generator in a professional context — populating database seeds, generating IDs for internal tooling, or normalizing UUIDs from production exports — you should not need to send that data to a third-party server.

At UPREK, our architecture is strict: your data stays yours. We don’t want it, we don’t collect it, and we can’t see it.

• 100% Local Generation: UUIDs are created using the browser-native crypto.randomUUID() API, or crypto.getRandomValues() as a fallback — both run entirely inside your browser’s JavaScript engine.
• Zero Server Uploads: No UUID you generate or paste into this tool is ever transmitted to our servers.
• No Logs or Storage: We do not log, store, or inspect any identifiers or input text you work with.
• Instant Deletion: All generated data exists only in your browser’s active memory. Close the tab and it is gone.

Frequently Asked Questions

Changelog