UUID Versions Explained: Choose Between v1, v4, v5, ULID, and NanoID
Compare common identifier formats by how they are generated, when they are useful, and why an identifier is not a password or encryption key.
UUIDs and similar identifiers help applications refer to records without relying on a short sequential number. The right format depends on whether you need random generation, repeatable names, or an identifier that sorts by time.
Choose a format for the job
- UUID v4: random-based; a common choice for independent identifiers when you do not need ordering.
- UUID v5: namespace and name based; the same inputs produce the same identifier, which is useful for deterministic references.
- UUID v1: time-based and includes node-related data; consider the privacy and ordering implications before choosing it.
- ULID: includes a time component and is designed to sort lexicographically by generation time.
- NanoID: a compact, configurable URL-friendly identifier format.
Use the UUID Generator to create v1, v4, v5, ULID, or NanoID values. For v5, enter the namespace and name consistently; changing either input changes the result.
Identifiers are not secrets
A UUID is not encryption and should not automatically be treated as a password, API key, or authorization token. If access depends on secrecy, use a purpose-built secret-generation and storage process. Avoid exposing identifiers that contain information you do not intend to disclose.
Validate before storing
Check the expected version and format at the application boundary, use a database type or constraint that matches your choice, and test how the identifier behaves in URLs and logs. If chronological sorting matters, verify the database’s ordering and the chosen format’s collision and privacy requirements before adopting it.