UUID Generator/ v4 · v7
Generate UUID v4 (random) and UUID v7 (time-ordered) in bulk. Supports uppercase, no-dash format, and one-click copy.
Count:
5 × UUID v4
85d0b27d-a8f3-40ac-b5cb-7f13b51210d9
c29caaa9-0d7f-4751-ad64-d45cf6538d2c
fe72a859-cacd-47af-93ff-44000dbe647f
c7954364-fd5d-4f13-b2a2-70f208056eda
9b01be09-4fa5-4bc9-ad6e-9845e503d1a0
UUID v4 uses 122 bits of cryptographic randomness. Collision probability with 1 trillion UUIDs is ~10⁻¹⁵ — effectively impossible.
Did this tool solve your problem?
What is a UUID
A UUID (Universally Unique Identifier) is a 128-bit identifier, typically shown as 32 hex characters like `550e8400-e29b-41d4-a716-446655440000`. UUID v4 is randomly generated with an astronomically low collision probability — you'd need to generate 103 trillion UUIDs for a 50% chance of one duplicate. Perfect for distributed system primary keys.
UUID version differences
v1 uses timestamp + MAC address (traceable), v3/v5 uses namespace + hash (deterministic), v4 is purely random (most common), v7 is time-sorted + random (new standard, balances ordering with randomness). v4 is standard for everyday development; v7 is ideal for database primary keys that need chronological ordering.
Code Examples
JavaScript / Node.js
// UUID v4 (browser & Node 19+)
const id = crypto.randomUUID();
// "110e8400-e29b-41d4-a716-446655440000"
// Node.js (< 19)
import { randomUUID } from "crypto";
const id = randomUUID();
// npm: uuid package
import { v4 as uuidv4, v7 as uuidv7 } from "uuid";
console.log(uuidv4());
console.log(uuidv7());Python
import uuid # UUID v4 print(uuid.uuid4()) # "a8098c1a-f86e-11da-bd1a-00112444be1e" # UUID v5 (name-based, deterministic) print(uuid.uuid5(uuid.NAMESPACE_DNS, "example.com")) # As hex (no dashes) print(uuid.uuid4().hex)
Go
// go get github.com/google/uuid import "github.com/google/uuid" // UUID v4 id := uuid.New() fmt.Println(id.String()) // UUID v7 (google/uuid v1.6+) id7, _ := uuid.NewV7() fmt.Println(id7.String())
SQL
-- PostgreSQL
SELECT gen_random_uuid(); -- v4
INSERT INTO users (id, name)
VALUES (gen_random_uuid(), 'Alice');
-- MySQL 8+
SELECT UUID(); -- v1 format
-- For v4: use application layer
-- SQLite (with extension or app)
SELECT lower(hex(randomblob(4))) || '-' ||
lower(hex(randomblob(2))) || '-4' ||
substr(lower(hex(randomblob(2))),2) || '-' ||
substr('89ab', abs(random()) % 4 + 1, 1) ||
substr(lower(hex(randomblob(2))),2) || '-' ||
lower(hex(randomblob(6)));Frequently Asked Questions
What is a UUID?
A UUID (Universally Unique Identifier) is a 128-bit identifier, typically represented as a 32-character hex string in 8-4-4-4-12 format (e.g., 550e8400-e29b-41d4-a716-446655440000). Defined by RFC 4122, it enables unique ID generation across distributed systems without central coordination.
What's the difference between UUID v4 and v7?
UUID v4 is fully random (122 bits), simple and universally supported. UUID v7 encodes a Unix millisecond timestamp in its first 48 bits, making it naturally time-ordered. This means database rows can be sorted by UUID to get creation-time order, with better B-tree index performance. UUID v7 is recommended for new projects.
How likely are UUID collisions?
UUID v4 uses 122 bits of randomness. You'd need to generate ~2^61 (~2.3 quintillion) UUIDs before a 50% collision probability. Generating millions per second in practice is completely safe for distributed primary keys.
UUID vs ULID — which is better?
ULID (Universally Unique Lexicographically Sortable Identifier) is similar to UUID v7 — time-ordered — but uses Crockford base32 encoding (26 characters, no dashes), making it shorter. UUID v7 is an IETF standard with broader ecosystem support; ULID is more compact for cases where shorter IDs are preferred.
How should I store UUIDs in a database?
PostgreSQL has a native UUID type. MySQL/MariaDB: use BINARY(16) for compact binary storage, or CHAR(36) for readability. MongoDB: use BinData(3) or a plain string. Always index UUID columns you query on.
Why does UUID v7 have better database performance than v4?
UUID v4's randomness causes random B-tree inserts, leading to frequent page splits and poor cache utilization at scale. UUID v7's time ordering means new rows append to the end of the index, similar to auto-increment IDs — dramatically better write performance and cache hit rates for large tables.