What Is a UUID?
A UUID (Universally Unique Identifier) is a 128-bit identifier standardized by RFC 4122. It looks like this:
550e8400-e29b-41d4-a716-446655440000
Five groups of hexadecimal characters separated by hyphens, always 36 characters long. The "universally unique" part comes from the combination of time, randomness, and/or namespace – depending on the version.
UUIDs are used when you need to generate IDs without a central authority (a database auto-increment counter). They are ideal for distributed systems, client-generated IDs, and cases where you cannot afford a round-trip to a server to get the next ID.
UUID Versions
There are several official UUID versions, each using a different generation strategy:
UUID v1 – Time-based
Generated from the current timestamp combined with the MAC address of the generating machine. Guaranteed to be unique across machines at the same moment, but the MAC address leaks machine identity – a security concern in some contexts.
UUID v3 – Name-based (MD5)
Deterministic: the same name + namespace always produces the same UUID. Uses MD5 hashing. Useful for generating stable IDs for well-known resources (a specific URL, a domain name). MD5 is considered cryptographically weak, so v5 is preferred for new projects.
UUID v4 – Random (most common)
Generated from 122 bits of random data. The most widely used version. The probability of a collision between two UUIDv4s is astronomically low (around 1 in 5.3 × 10³⁶ for any two given IDs). Use this unless you have a specific reason not to.
UUID v5 – Name-based (SHA-1)
Same as v3 but uses SHA-1 instead of MD5. Preferred over v3 for new work. Great for generating stable, reproducible identifiers from input strings.
UUID v7 – Time-ordered random (new standard)
Introduced in the 2022 revision of the RFC. Combines a millisecond-precision timestamp prefix with random bits. The timestamp prefix means UUIDv7s sort chronologically – a major advantage for database primary keys (better index performance than random v4). This is the recommended choice for database IDs going forward.
When to Use UUIDs
- Database primary keys – especially in distributed systems where multiple nodes insert records concurrently
- API resource identifiers – exposing sequential integers leaks information about your data volume; UUIDs do not
- File and asset naming – collision-resistant names for uploaded files without a coordination server
- Idempotency keys – generating a client-side key to safely retry a payment or mutation request
UUID vs ULID vs NanoID
UUID v4 is random but unsortable. Alternatives have emerged for specific use cases:
ULID (Universally Unique Lexicographically Sortable Identifier): a 128-bit ID like UUID but sortable by time. Similar goal to UUID v7.
NanoID: smaller (21 characters by default), URL-safe, configurable alphabet. Useful when you want short IDs in URLs. The collision probability is tunable by adjusting length.
For most backend database work, UUID v7 is the modern best practice. For URL-friendly short IDs, NanoID is a popular choice. UUID v4 remains the most universally supported option when compatibility is the priority.
Generating UUIDs in Your Browser
You can generate UUID v4 (and other versions) instantly with the UUID Generator on this site – no sign-up, no server round-trip, runs entirely in your browser.
In code: JavaScript has crypto.randomUUID() natively in modern browsers and Node.js ≥ 14.17. Python has the uuid standard library module.
Summary
UUIDs are 128-bit collision-resistant identifiers with multiple versions for different strategies: time-based (v1), random (v4), name-based (v5), and time-ordered random (v7). UUID v4 is the most common general-purpose choice; UUID v7 is the best choice for database primary keys where sort order matters.