Crunchify.net

UUID Generator

Generate random, deterministic, and time-ordered UUIDs.

Hex case:
Bulk Generation

How It Works

v4 uses crypto.randomUUID() — cryptographically random, 122 bits of entropy. The probability of a collision across 1 billion UUIDs is about 1 in 1018.

v5 generates a deterministic UUID from a namespace and a name using a SHA-1 hash. The same inputs always produce the same UUID. Useful for stable IDs derived from natural keys — for example, a consistent UUID for a domain name or a database row identified by a natural key.

v7 embeds a 48-bit Unix millisecond timestamp in the first 6 bytes, followed by random bits. Because the timestamp comes first, v7 UUIDs sort lexicographically in generation order — making them well-suited as primary keys in databases where UUID ordering matters for index performance.

Base64 encoding represents the 16 raw UUID bytes as a 24-character string (22 characters in base64url without padding). Useful when you need a compact, URL-safe identifier.

Related Tools

Cron Expression Parser CIDR / Subnet Calculator JWT Decoder CSV ↔ JSON Converter Regex Tester Hash Generator Number Base Converter Unix Timestamp Converter JSON Formatter

Frequently Asked Questions

What is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit identifier formatted as 8-4-4-4-12 hexadecimal characters, e.g. 550e8400-e29b-41d4-a716-446655440000. They are designed to be globally unique without requiring a central registry.

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

v4 is completely random (122 bits of entropy). v5 is deterministic — the same namespace + name always produces the same UUID, using SHA-1. v7 encodes a millisecond timestamp in the first 48 bits so UUIDs sort in generation order — ideal for database primary keys.

What are the chances of a UUID collision?

Extremely small for v4. With 1 billion UUIDs, the probability of any collision is about 1 in 10^18. Generating a duplicate UUID in practice is essentially impossible.

Why use UUID v7 instead of v4 for database primary keys?

v4 UUIDs are random, causing random writes across a B-tree index — expensive for inserts at scale. v7 UUIDs are time-ordered, so new rows insert at the end of the index like an auto-incrementing integer, preserving locality and insert performance.