Developer Tools

Free UUID Generator Online

Generate cryptographically random UUID v4 identifiers in one click.

What is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit label used to uniquely identify objects in computer systems without requiring a central authority to assign them. The standard format is 32 hexadecimal digits displayed in five groups separated by hyphens: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. The specification is defined in RFC 4122.

This tool generates Version 4 UUIDs — randomly generated using window.crypto.randomUUID(), the same Web Crypto API your browser uses for secure operations. With 122 bits of entropy, the probability of generating two identical UUIDs is approximately 1 in 5.3 × 10³⁶.

How to generate UUIDs

1
Set the count
Use the count input to generate between 1 and 50 UUIDs at once. Useful for seeding databases or generating test fixtures.
2
Toggle uppercase if needed
Some systems require uppercase UUIDs. Click the UPPERCASE toggle to switch between formats — the value is identical either way.
3
Click Generate
A new set of cryptographically random UUIDs is generated immediately. Each click produces a completely new set.
4
Copy individually or all at once
Click the copy icon next to any UUID to copy it, or use Copy All when you need multiple UUIDs as a newline-separated list.

When to use UUIDs

Database primary keys

UUIDs allow distributed systems to generate IDs independently without coordination. Preferred over auto-increment when merging databases.

API resource identifiers

Expose UUIDs in REST API endpoints instead of sequential integers to avoid leaking record counts and prevent enumeration attacks.

Session tokens

Use UUIDs as session, request, or correlation IDs for tracing requests across microservices.

File names

Generate UUID-based file names when storing uploads to avoid collisions and prevent predictable paths.

Idempotency keys

Send a UUID with each API request as an idempotency key to safely retry requests without duplicate operations.

Test data generation

Generate bulk UUIDs to seed test databases, mock fixtures, or populate staging environments.

UUID versions compared

The UUID specification defines eight versions (v1 through v8), each using a different algorithm to generate the identifier. Version 4 (random) is by far the most widely used, but the other versions each solve specific problems:

v1 — Time-based

Algorithm: Combines the current timestamp with the MAC address of the generating machine

Pros: Monotonically increasing within a node; sortable by creation time

Cons: Exposes MAC address (privacy risk); not suitable for distributed systems where time can skew

v3 — Name-based (MD5)

Algorithm: MD5 hash of a namespace UUID and a name string

Pros: Deterministic — same namespace + name always produces the same UUID

Cons: MD5 is cryptographically broken; prefer v5 for new applications

v4 — Random

Algorithm: 122 bits of cryptographically secure random data

Pros: No privacy leakage; no coordination needed; universally supported

Cons: Not sortable; not deterministic; marginally higher collision risk than time-based versions (still negligible in practice)

v5 — Name-based (SHA-1)

Algorithm: SHA-1 hash of a namespace UUID and a name string

Pros: Deterministic like v3 but uses SHA-1 instead of MD5; useful for content-addressable IDs

Cons: SHA-1 is deprecated for cryptographic use, though acceptable here since UUID generation is not a security operation

v6 — Reordered time

Algorithm: Time-based like v1 but with the time bits reordered for lexicographic sortability

Pros: Sortable by creation time while maintaining compatibility with the UUID format

Cons: Still exposes node (MAC) data; less adoption than v7

v7 — Unix timestamp + random

Algorithm: Unix millisecond timestamp in the high bits, random bits in the low bits

Pros: Lexicographically sortable by creation time; no MAC address exposure; excellent for database primary keys

Cons: Newer standard (RFC 9562, 2024); library support still catching up

UUID vs alternatives — ULID, NanoID, CUID

UUID v4 is the default choice but is not always optimal. Several alternatives have emerged to address specific shortcomings:

ULID

01ARZ3NDEKTSV4RRFFQ69G5FAV

Universally Unique Lexicographically Sortable Identifier. Encodes a 48-bit millisecond timestamp + 80 random bits in 26 Crockford Base32 characters. URL-safe, case-insensitive, and lexicographically sortable. Excellent for database keys where insertion order should match sort order.

NanoID

V1StGXR8_Z5jdHi6B-myT

A tiny, secure, URL-safe unique string ID generator. 21 characters by default, configurable length and alphabet. Smaller output than UUID, no hyphens, works in all environments. The go-to choice for URL slugs, session IDs, and short identifiers in Node.js/browser apps.

CUID2

clh3y4z9z0000q1n7lk7b3k8m

Collision-resistant unique ID. Designed for horizontal scaling and safe exposure in URLs. Lowercase, starts with a letter (unlike UUIDs which can start with a digit), fingerprint-based to reduce collision risk across machines.

UUID v7

018e2ce9-4aef-7b9c-8190-4d0a4b35d9e0

The modern UUID standard (RFC 9562, 2024). Embeds a Unix millisecond timestamp in the first 48 bits, making UUIDs sortable by creation time — a huge benefit for database performance. Best of both worlds: UUID compatibility + ULID-like sortability.

UUID best practices for backend developers

Using UUIDs effectively in production systems requires understanding the performance tradeoffs and common pitfalls. Here are the patterns that experienced engineers follow:

Prefer UUID v7 for database primary keys

UUID v4 is fully random — B-tree index pages split constantly as new rows land at random positions. UUID v7 embeds a millisecond timestamp so new rows cluster near the end of the index, dramatically reducing write amplification and fragmentation at scale.

Store as BINARY(16), not CHAR(36)

The hyphenated string wastes 20 bytes versus the 16-byte binary form. MySQL: use BINARY(16) with UNHEX(REPLACE(uuid,"-","")). PostgreSQL has a native UUID type that stores 16 bytes automatically.

Never expose sequential IDs publicly

Auto-increment IDs reveal your record count and enable enumeration attacks. Replace public-facing IDs with UUIDs. Keep integer primary keys internal for foreign keys and joins.

Validate at the API boundary

Before using a UUID from user input in a query, validate the 8-4-4-4-12 hex format. An invalid UUID may cause silent type coercion in some databases.

Add expiry for token use cases

UUID v4 cannot be guessed by brute force — great for password reset links. But always store a creation time server-side and mark the token used after redemption. UUID alone does not expire.

UUID collision probability and security

UUID v4's 122 bits of randomness make it statistically impossible to guess a valid identifier by brute force. This makes UUIDs an excellent choice for public-facing resource identifiers — shareable document URLs, order confirmation links, file upload paths. An attacker cannot enumerate resources: guessing the next valid UUID requires trying approximately 5.3 × 10³⁶ possibilities.

Collision probability is similarly negligible. To have a 1% chance of generating a duplicate within your system, you would need to have already generated approximately 2.6 × 10¹⁷ UUIDs. At one million per second, reaching that number would take over 8,000 years.

The one caveat is random number generator quality. Use only CSPRNG-backed generators: the browser's crypto.randomUUID(), Python's uuid.uuid4(), or PostgreSQL's gen_random_uuid(). Avoid any library that seeds from a timestamp or weak random source — those UUIDs are predictable and defeat the purpose entirely.

FAQ

Common questions

What is a UUID?

UUID (Universally Unique Identifier) is a 128-bit label used to uniquely identify objects in computer systems. The standard format is 32 hex digits split by hyphens: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.

What is UUID v4?

Version 4 UUIDs are randomly generated. They use cryptographically secure randomness, making collisions astronomically unlikely — roughly 1 in 5.3 × 10³⁶ chance for any two v4 UUIDs to match.

Are these UUIDs unique?

Yes. This tool uses window.crypto.randomUUID() — the same Web Crypto API your browser uses for secure operations. All generation is local; nothing is stored or transmitted.

When should I use UUIDs?

UUIDs are ideal for database primary keys, session tokens, file names, API resource IDs, and anywhere you need a globally unique identifier without a central authority.

What is the difference between uppercase and lowercase UUIDs?

They are functionally identical — UUID is case-insensitive by specification. Lowercase is the most common convention in modern systems, but some legacy systems expect uppercase.

What is the difference between UUID v1, v4, and v7?

UUID v1 encodes the current timestamp and MAC address — sortable but leaks machine identity. UUID v4 is fully random — no ordering, maximum privacy. UUID v7 (2024 draft standard) encodes a millisecond timestamp in the first 48 bits plus random data, making it both random and time-sortable. For new database primary keys, UUID v7 is increasingly recommended because it maintains index locality.

Should I use UUIDs or auto-increment integers as database primary keys?

Both have valid uses. Auto-increment integers are smaller (4–8 bytes vs 16 bytes), more readable, and slightly faster to index. UUIDs are globally unique across databases and services, making them ideal for distributed systems, multi-tenant databases, and anywhere IDs are exposed in public URLs (integers reveal row counts). UUID v7 reduces the index fragmentation downside of v4.

How do I generate UUIDs in code without a library?

In modern environments: JavaScript/Node.js: crypto.randomUUID(). Python 3.x: import uuid; str(uuid.uuid4()). Go: use the github.com/google/uuid package. Rust: use the uuid crate. In PostgreSQL, use gen_random_uuid() (built-in since v13) or uuid_generate_v4() from the uuid-ossp extension. All of these use cryptographically secure randomness.