Cryptographically random. Most widely used.
A UUID (Universally Unique Identifier) is a 128-bit identifier standardized by RFC 4122. It is always 36 characters long — 32 hex digits split into 5 groups by hyphens. One digit encodes the version and another the variant:
This tool supports all four major UUID versions: v1 (time-based), v4 (random), v5 (name-based), and v7 (Unix timestamp sortable).
Encodes the current timestamp plus a random node ID. The creation time is baked into the first three groups of the UUID.
Best for: Systems where you want rough time-ordering or need to trace when an ID was created.
Fully random — 122 bits of cryptographic randomness from the Web Crypto API. The most common UUID version. Collision probability: 1 in 2122.
Best for: Database keys, session tokens, API IDs — the default choice for most developers.
Deterministic — given the same namespace and name, the output UUID is always identical. It hashes the namespace + name with SHA-1.
Best for: Deduplication, or when you need a stable ID for a known resource like a domain or URL.
Embeds a Unix millisecond timestamp in the first 12 hex characters. UUIDs generated later are always larger, so they sort naturally by time.
Best for: Database primary keys in PostgreSQL / MySQL — keeps index pages ordered and reduces fragmentation.
Use v7 for sequential index efficiency in PostgreSQL and MySQL, or v4 for simplicity when sort order doesn't matter.
Use v4 for session tokens, CSRF tokens, API keys, and idempotency keys where strong randomness is the priority.
Use v5 with the URL or DNS namespace to generate stable, reproducible UUIDs for known resources — same input always gives the same ID.
Use v7 or v1 to attach time-encoded trace IDs to API requests, making it easy to correlate events across microservices by time.
Use v4 for upload filenames and cache keys. Use v5 to derive consistent IDs from known filenames or content hashes.
Use v5 when you want to detect duplicates: hashing the same content with the same namespace always produces the same UUID, so duplicates are automatically identified.
.txt file.Generate v1 (time), v4 (random), v5 (name-based SHA-1), and v7 (Unix timestamp) — all in one tool with instant switching.
Generate up to 100 UUIDs at once. Copy all with a single click or download as a .txt file for bulk use.
All UUID generation runs in your browser using the Web Crypto API. No data is ever sent to any server — fully private.
v1 encodes the current timestamp and a random node — good for time-traceable IDs but leaks generation time. v4 is fully random (122 random bits) — the most common choice. v5 is deterministic: SHA-1 hash of a namespace + name — the same inputs always produce the same UUID. v7 is a modern RFC 9562 format with a Unix millisecond timestamp prefix — ideal for database index performance.
Use v7 when UUIDs are used as database primary keys. Because v7 embeds a millisecond timestamp in the high bits, rows inserted in order produce monotonically increasing UUIDs. This dramatically reduces B-tree index fragmentation in PostgreSQL, MySQL, and SQLite compared to random v4 UUIDs.
UUID v5 generates a deterministic identifier from a namespace UUID and a name string using a SHA-1 hash. Example: hashing the DNS namespace with example.com always produces cfbff0d1-9375-5685-98e9-e4b2be7d4d59. This makes v5 ideal for deduplication — if the same resource appears twice, it gets the same ID automatically.
Extremely unique. With 122 random bits, you would need to generate roughly 2.71 quintillion (2.71 × 1018) UUIDs to reach a 50% probability of even a single collision. For all practical purposes, collisions are effectively impossible.
They are the same thing. GUID (Globally Unique Identifier) is Microsoft's term used in Windows and .NET. UUID is the standard term defined in RFC 4122. Structurally identical — 128-bit, same hyphenated format.
Yes. For random access patterns, v4 works well in PostgreSQL (uuid column type) and MongoDB. For insert-heavy workloads where index locality matters, prefer v7 — its timestamp prefix keeps new rows near the end of the index, avoiding page splits and improving write throughput.