UUID Generator
Generate and validate UUIDs. Fast, secure, and works offline.
UUID Generator
๐ Need help choosing? Click for specific use cases
UUID
UUID/ULID Information
๐ Official Documentation:
- โข RFC 4122 - Original UUID specification (v1-v5)
- โข RFC 9562 - Updated UUID specification (v6-v8, 2024)
- โข ULID Specification - Canonical ULID spec
- โข Wikipedia: UUID - Comprehensive overview
โฐ UUID v1 - Time-based (legacy)
Use case: Database primary keys, legacy systems, distributed systems needing temporal ordering
Pros: Excellent for database indexing, natural chronological sorting, unique across space and time
Cons: Contains MAC address and timestamp - consider privacy implications for public-facing applications
โ ๏ธ UUID v2 - DCE Security (Reserved)
Reserved for Distributed Computing Environment (DCE) security UUIDs. Rarely used due to complexity. See https://en.wikipedia.org/wiki/Distributed_Computing_Environment
โ ๏ธ๐ UUID v3 - MD5 hash (deprecated)
Use case: When you need the same UUID for the same input every time
Example: User "john@example.com" always gets UUID "550e8400-e29b-41d4-a716-446655440000". Perfect for migration or data sync.
Good for: User migration, data synchronization, reproducible UUIDs across systems
Note: Deprecated: MD5 has security flaws. Use v5 for new projects needing deterministic UUIDs
๐ฒ UUID v4 - Random (Most Popular)
Use case: General purpose, APIs, session IDs, file identifiers
Example: User IDs, order IDs - anything needing uniqueness without temporal ordering
Why popular: Simple, secure, no dependencies on MAC/time
Database caveat: Random nature can cause index fragmentation and poor insert performance
๐ UUID v5 - SHA-1 hash
Use case: Same as v3 - deterministic UUIDs from names
Example: Same concept as v3 but cryptographically secure
Good for: Preferred alternative to v3 for all new projects
โฐ UUID v6 - Time-ordered (RFC 9562)
Design: Same as v1 but with timestamp bits reordered from most to least significant
Use case: Database performance with lexicographic sorting by creation time
Advantage: Enables sorting UUIDs by creation time simply by sorting lexically, unlike v1
โฐ UUID v7 - Unix timestamp (RFC 9562)
Design: 48-bit Unix timestamp + 80-bit randomness (similar concept to ULID)
Use case: Modern applications needing sortable IDs with Unix timestamps
Benefits: Lexicographically sortable, standard UUID format, excellent database performance
โฐ ULID - Lexicographically Sortable
Design: 48-bit timestamp + 80-bit randomness, Base32 encoded (26 characters)
Use case: APIs and databases where you want readable, sortable IDs
Features: URL-safe, case-insensitive, lexicographically sortable, millisecond precision
ULID vs UUID v7 - Historical Context ๐
Timeline: ULID was created first to solve UUID sortability problems
UUID v7 inspiration: UUID v7 (RFC 9562, 2024) took inspiration from ULID's design
Key difference: ULID uses Base32 encoding (26 chars), UUID v7 uses standard UUID format (36 chars)
Current trend: UUID v7 is becoming preferred for new projects due to official standardization
๐ก Common use cases:
- General purpose: Most web apps and APIs: v4 (widely supported, but avoid as DB primary keys)
- Database keys: DB primary keys: v6, v7, or ULID (better insert performance)
- Time-ordered data: Chronological sorting: v1, v6, v7, or ULID
- Deterministic UUIDs: Same input = same UUID: v5 (or v3 for legacy)
- Legacy systems: Existing systems: Keep current version
- Public APIs: External APIs: v4 or ULID