UUID Generator

Generate UUID v4 (random) or UUID v7 (time-sortable, RFC 9562). Bulk up to 100. Decode any UUID.

Version

Quantity (1–100)

Related Tools

What Is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit number used to uniquely identify information in computer systems — without requiring a central authority to coordinate. The format is standardised as 32 hexadecimal characters divided into 5 groups by hyphens: 550e8400-e29b-41d4-a716-446655440000. The probability of generating two identical UUIDs by accident is so small it is considered practically impossible.

UUIDs are used everywhere in modern software: as primary keys in databases, as request IDs for distributed tracing, as session identifiers, as file names for uploads, and as identifiers in message queues. If you have ever seen a long string of hex characters in a URL, database, or API response, it was almost certainly a UUID.

UUID Versions — Complete Guide

Version	Method	Best For	Still Relevant?
v1	Timestamp + MAC address	Legacy systems	Rarely — leaks hardware info
v2	DCE Security (UID/GID)	POSIX systems	No — very rarely used
v3	MD5 hash of namespace+name	Deterministic IDs	Sometimes
v4	Random	General purpose IDs	Yes — most common
v5	SHA-1 hash of namespace+name	Better than v3	Sometimes
v6	Reordered v1 timestamp	Migration from v1	Niche
v7	Unix timestamp + random	Database primary keys	Yes — new standard (2024)
v8	Custom	Application-specific	Experimental

UUID v4 — The current standard for random IDs

UUID v4 fills 122 of its 128 bits with cryptographically random data (6 bits are reserved for version and variant markers). It has no structure, no time information, and no relationship between any two generated values. The probability of collision — generating the same UUID twice — is 1 in 5.3 × 10^36. To put that in perspective: if you generated 1 billion UUIDs per second for 100 years, your chance of a single collision would still be essentially zero.

v4 is the right choice when you need an ID that is completely unpredictable, carries no metadata, and is safe to expose publicly (e.g. in URLs) without leaking any information about when or where it was generated.

UUID v7 — The 2024 standard for sortable IDs

UUID v7 was standardised in RFC 9562 in May 2024. It embeds a 48-bit Unix timestamp in milliseconds in the first 48 bits, followed by random data. This gives v7 two properties that v4 lacks: temporal ordering and database-friendly insertion patterns.

UUID v7 structure:
┌─────────────────────────────────────────────────────────┐
│ Bits 0–47:   Unix timestamp (milliseconds)              │
│ Bits 48–51:  Version marker (0111 = version 7)          │
│ Bits 52–63:  Random or sequence counter                 │
│ Bits 64–65:  Variant (10)                               │
│ Bits 66–127: Random                                     │
└─────────────────────────────────────────────────────────┘

Example: 018d7a3b-c4e2-7f8a-9b3c-1a2b3c4d5e6f
         └─────────┘ ← Timestamp embedded here

💡 UUID v7 is now the recommended choice for database primary keys in new applications. PostgreSQL 17, MySQL 9.0, and most modern ORMs have native support for UUID v7.

Why UUID v7 Is Better Than v4 for Database Keys

The index fragmentation problem with v4

Database indexes (B-trees) store records in sorted order. When you insert a new record, the database must find the right position in the sorted index. With UUID v4, every new ID is random — so each insert goes to a random position in the index. This causes "index fragmentation": the index pages fill up unevenly, pages split frequently, and the physical storage becomes scattered across disk.

On a large table (100 million+ rows), UUID v4 primary keys can cause insert performance to degrade by 30–70% compared to sequential IDs. Cache hit rates drop because the data is scattered. Index pages need to be read from disk rather than served from memory.

How UUID v7 solves this

UUID v7's timestamp prefix means new IDs are always larger than existing ones — they insert at the end of the index, just like auto-increment integers. Index pages fill sequentially, no pages split unexpectedly, and cache efficiency is maintained. Benchmarks show UUID v7 insert performance is 80–90% as fast as integer auto-increment, compared to 30–50% for UUID v4 on large tables.

UUID vs Other ID Formats

Format	Example	Size	Sortable?	Readable?	Use Case
UUID v4	550e8400-e29b-41d4-a716	36 chars	No	Low	General distributed IDs
UUID v7	018d7a3b-c4e2-7f8a-9b3c	36 chars	Yes	Low	Database primary keys
ULID	01ARZ3NDEKTSV4RRFFQ69G5FAV	26 chars	Yes	Medium	Alternative to UUID v7
NanoID	V1StGXR8_Z5jdHi6B-myT	21 chars	No	Medium	URL-safe compact IDs
CUID2	clh3etscf0000356zz0qh6y3h	25 chars	Yes	Medium	Collision-resistant IDs
Integer	1234567890	Up to 19	Yes	High	Simple sequential IDs

How to Use UUIDs in Different Languages

// JavaScript (browser - built-in)
const id = crypto.randomUUID(); // v4
// Output: 'f47ac10b-58cc-4372-a567-0e02b2c3d479'

// Node.js
import { randomUUID } from 'crypto';
const id = randomUUID(); // v4

// 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

// Go
import "github.com/google/uuid"
id := uuid.New().String() // v4
id7, _ := uuid.NewV7()    // v7

// PostgreSQL
SELECT gen_random_uuid();           -- v4
SELECT uuid_generate_v4();          -- v4 (uuid-ossp extension)

// MySQL 8.0+
SELECT UUID();                      -- v1 (use UUID_TO_BIN for efficiency)

// MongoDB
// Uses ObjectID by default, not UUID (but can store UUIDs)

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

It depends on your architecture. Auto-increment integers are simpler, smaller (8 bytes vs 16 bytes), and faster for single-database setups. UUIDs are better for distributed systems (multiple databases, microservices, offline-capable apps) where you need to generate IDs independently without a central coordinator. UUID v7 is a good compromise: distributed generation with near-integer index performance.

Are UUIDs safe to use in public URLs?

UUID v4 is safe — it reveals nothing about your data. UUID v7 reveals when the record was created (the timestamp is embedded), which is usually acceptable but worth noting. Never use v1 in public URLs as it embeds your MAC address.

What is the difference between UUID and GUID?

GUID (Globally Unique Identifier) is Microsoft's term for the same concept. GUIDs follow the same RFC 4122 standard as UUIDs and are interchangeable. The terms are used differently by convention: UUID is standard in Unix/web contexts; GUID is standard in Microsoft/.NET contexts.

How do I store UUIDs efficiently in a database?

Store as BINARY(16) not VARCHAR(36) to save 20 bytes per row. In PostgreSQL, use the native UUID type. In MySQL, use UUID_TO_BIN() when inserting and BIN_TO_UUID() when selecting. For UUID v7, store as BINARY(16) with the timestamp bits first for optimal index performance.

Can I extract the creation time from a UUID?

Only from UUID v1, v6, and v7. UUID v7 stores the Unix timestamp in milliseconds in the first 48 bits — extract it with bit manipulation or use a library. UUID v4 is purely random and contains no time information.