UUID (Universally Unique Identifier) and GUID (Globally Unique Identifier) are two names for essentially the same thing. GUID is Microsoft's term, used in Windows, COM, ActiveX, and .NET. UUID is the term used in the IETF standard (RFC 4122) and across most of the rest of the technology world. Both represent a 128-bit identifier formatted as 32 hexadecimal digits in five groups: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. The key practical difference is version.
UUID Versions Explained
- UUIDv1: Time-based — includes the current timestamp and MAC address. Sortable by creation time but leaks network information.
- UUIDv2: DCE Security — rarely used, designed for POSIX UID/GID. Avoid.
- UUIDv3: Name-based, MD5 hash — deterministic: same inputs always produce the same UUID. Use for namespaced identifiers.
- UUIDv4: Random — 122 bits of cryptographically random data. The most widely used version. What this tool generates.
- UUIDv5: Name-based, SHA-1 hash — like v3 but using SHA-1. Preferred over v3 when determinism is needed.
- UUIDv7: Time-ordered random — new (RFC 9562, 2024). Combines millisecond timestamp prefix with random data. Sortable like v1, privacy-safe like v4. Growing adoption.
Why UUIDv4 Is the Default Choice
UUIDv4 uses 122 bits of cryptographic randomness. The probability of generating two identical UUIDs is 1 in 5.3 × 10³⁶ — so low it is treated as impossible in practice. UUIDv4 leaks no information about the generating system (unlike v1 which includes a MAC address). It is supported natively by all major programming languages and databases. Its only weakness is that it is not sortable by generation order, which can cause index fragmentation in B-tree databases.
UUIDv7: The Modern Alternative
UUIDv7, standardized in RFC 9562 (May 2024), prefixes each UUID with the current Unix timestamp in milliseconds, followed by random data. This makes UUIDv7 values sortable in chronological order while remaining globally unique and privacy-safe. PostgreSQL 17 added native UUIDv7 support. For new database primary key designs, UUIDv7 is increasingly preferred over UUIDv4 because sorted primary keys dramatically reduce B-tree index fragmentation.
When to Use UUIDs
- Database primary keys in distributed systems where auto-increment IDs would conflict across nodes
- API resource identifiers in REST endpoints (/users/f47ac10b-58cc-4372-a567-0e02b2c3d479)
- Idempotency keys in payment APIs to prevent duplicate charge processing
- Session tokens and tracking identifiers
- File naming to prevent collisions when multiple users upload simultaneously
- Message queue message IDs for deduplication
When NOT to Use UUIDs
UUIDs are not optimal for: short URLs or user-facing identifiers (36 characters is unwieldy compared to an 8-character alphanumeric code), sequential log entries where ordering is essential and UUIDv4 would randomize the index, or systems with very high insert rates where index fragmentation from random UUIDs becomes a measurable performance issue (use UUIDv7 or ULID instead).