Developer Tools for Random Data Generation // v2.13.1
root@generate-random:~/uuid-v5$ _

Random UUID v5 Generator

Generate namespace-based UUID version 5 identifiers using SHA-1 hashing - deterministic, reproducible UUIDs with stronger cryptographic hash than v3

Our UUID v5 generator creates namespace-based universally unique identifiers using SHA-1 hashing per RFC 4122 standards. Generate UUID version 5 from namespace identifiers (DNS, URL, OID, X.500) and custom names for deterministic, reproducible unique IDs with stronger collision resistance than MD5-based v3. Perfect for content-addressed storage, database migrations, API integrations, and systems requiring secure deterministic UUID generation where the same namespace and name consistently produce identical results.

What is UUID v5?

UUID v5 (Universally Unique Identifier version 5) is a namespace-based identifier defined in RFC 4122 that uses SHA-1 hashing to generate deterministic UUIDs. It combines a predefined namespace identifier (DNS, URL, OID, or X.500) with a custom name string, then applies SHA-1 hashing to produce a 128-bit UUID. Like v3, UUID v5 is deterministic - the same namespace and name always generate the identical UUID - but v5 uses SHA-1 (160-bit hash) instead of MD5 (128-bit hash), providing stronger collision resistance and better security properties, making it the recommended choice for namespace-based UUID generation in new projects.

The format follows the standard 32 hexadecimal digits in 5 groups: 8-4-4-4-12 (e.g., 886313e1-3b8a-5372-9b90-0c9aee199e5d). The version field (5) indicates SHA-1-based generation, while variant bits ensure RFC 4122 compliance. UUID v5 is ideal for database migrations requiring consistent IDs across environments, content-addressed storage where identical content must produce identical UUIDs, API integrations with deterministic identifier requirements, and testing scenarios needing reproducible fixtures. While SHA-1 is deprecated for cryptographic security (signatures, certificates), it remains perfectly suitable for UUID generation where collision resistance and determinism are priorities over cryptographic strength.

UUID v5 Configuration Options

Namespace Selection

Choose from RFC 4122 predefined namespaces: DNS (domain names), URL (web addresses), OID (object identifiers), or X.500 (directory names). The namespace ensures globally unique UUIDs across different naming contexts while maintaining deterministic generation.

Multiple Names (One Per Line)

Enter multiple name strings (one per line) to generate unique UUIDs. Each name is hashed with SHA-1 combined with the selected namespace. The same namespace + name combination always produces identical UUIDs (deterministic), but different names generate different UUIDs - perfect for batch generation in migrations and content addressing.

How to Generate UUID v5

[STEP 1] Select Namespace

Choose the appropriate RFC 4122 namespace: DNS for domain names, URL for web addresses, OID for object identifiers, or X.500 for directory names. The namespace prevents collisions between identically-named entities in different contexts.

[STEP 2] Enter Names

Enter one or more names (one per line) to be hashed with SHA-1. For DNS namespace, use domain names (example.com). For URL namespace, use complete URLs. Each name is combined with namespace UUID and hashed to produce a unique deterministic identifier.

[STEP 3] Generate & Verify

Click EXECUTE GENERATION to create namespace-based UUIDs with SHA-1 hashing. Verify determinism by regenerating with identical namespace and name - you'll always receive the same UUID, confirming reproducible generation.

[STEP 4] Use Consistently

Use UUID v5 for database migrations (consistent IDs across environments), content-addressed storage (same content = same UUID), API integrations requiring deterministic identifiers, and testing with reproducible fixtures.

UUID v5 Best Practices

  • _ Prefer v5 Over v3 - For new projects requiring namespace-based UUIDs, always choose v5 (SHA-1) over v3 (MD5). SHA-1 provides better collision resistance and security properties despite both being deprecated for cryptographic use.
  • _ Namespace Consistency - Always use the same namespace for the same type of data. Use DNS for domains, URL for web resources, OID for standardized identifiers, and X.500 for directory entries to prevent accidental collisions.
  • _ Deterministic Advantage - Leverage v5's reproducibility for database migrations, ensuring identical entities receive identical UUIDs across multiple migration runs or different environments (dev, staging, production).
  • _ Content Addressing - Ideal for content-addressed storage systems, deduplication, and distributed caching where the same input data must always produce the same identifier for efficient lookups.
  • _ Testing Benefits - Use v5 for test fixtures and development data where predictable UUIDs simplify debugging, test assertions, and snapshot testing. Reproducibility makes tests deterministic.
  • _ Security Caveat - While SHA-1 is stronger than MD5, it's cryptographically broken for security purposes. Never use v5 for authentication tokens or cryptographic keys. Use v4 (random) or dedicated token generators for security-sensitive applications.

UUID v5 Generation Algorithm

UUID v5 follows RFC 4122 specification, using SHA-1 hashing to combine namespace and name into a deterministic 128-bit identifier with stronger collision resistance than MD5-based v3:

// UUID v5 Structure (128 bits from SHA-1 hash)
Algorithm: Namespace-Based UUID with SHA-1

// Predefined Namespace UUIDs (RFC 4122)
DNS: 6ba7b810-9dad-11d1-80b4-00c04fd430c8
URL: 6ba7b811-9dad-11d1-80b4-00c04fd430c8
OID: 6ba7b812-9dad-11d1-80b4-00c04fd430c8
X500: 6ba7b814-9dad-11d1-80b4-00c04fd430c8

// Generation Algorithm
1. Convert namespace UUID to 16-byte binary
2. Concatenate namespace bytes + name string (UTF-8)
3. Hash = SHA1(namespace_bytes + name_bytes)
4. Truncate hash to first 128 bits (16 bytes)
5. Set version bits: hash[6] = (hash[6] & 0x0F) | 0x50
6. Set variant bits: hash[8] = (hash[8] & 0x3F) | 0x80

// SHA-1 Output: 160 bits → Truncate to 128 bits
Collision Resistance: 2^128 (stronger than MD5)

// Format: xxxxxxxx-xxxx-5xxx-yxxx-xxxxxxxxxxxx
Example: 886313e1-3b8a-5372-9b90-0c9aee199e5d

// Determinism Property
namespace="DNS", name="example.com" → Always same UUID
namespace="URL", name="https://example.com" → Different UUID

// Comparison with v3
v3 (MD5): 128-bit hash, 2^64 collision resistance
v5 (SHA-1): 160-bit hash, 2^80 collision resistance
Recommendation: Use v5 for new projects

UUID v5 API for Developers

Generate UUID v5 identifiers programmatically using our free REST API. Provide namespace and name parameters for deterministic SHA-1-based UUID generation perfect for database migrations and content addressing.

Example API calls for UUID v5:

  • GET /api/v1/generate/uuids?version=5&namespace=dns&name=example.com - Generate UUID v5 for DNS namespace
  • GET /api/v1/generate/uuids?version=5&namespace=url&name=https://example.com&count=10 - Bulk generation
  • Response includes formatted UUIDs, namespace used, and name parameter for verification

Same namespace + name combination always returns identical UUID, ensuring deterministic generation across multiple API calls.

GET https://generate-random.org/api/v1/generate/uuids
VIEW FULL API DOCUMENTATION

Frequently Asked Questions

What's the difference between UUID v5 and v3?
Both are namespace-based and deterministic, but UUID v5 uses SHA-1 hashing (160 bits, stronger) while v3 uses MD5 hashing (128 bits, weaker). SHA-1 provides better collision resistance and security properties. Always prefer v5 for new projects - use v3 only for compatibility with legacy systems that specifically require MD5-based UUIDs. Both are suitable for deterministic ID generation despite being deprecated for cryptographic security purposes.
Is UUID v5 secure for authentication or tokens?
No. While SHA-1 is stronger than MD5, it's cryptographically broken and should not be used for security-sensitive purposes like authentication tokens, API keys, digital signatures, or cryptographic keys. Use UUID v4 (cryptographically random) or dedicated secure token generators (JWT, OAuth tokens) for security applications. UUID v5 is perfectly suitable for deterministic identifier generation where reproducibility matters more than unpredictability.
Why choose UUID v5 over v4?
Choose v5 when you need determinism - the same input always produces the same UUID. This is essential for database migrations (consistent IDs across runs), content-addressed storage (same content = same ID), API integrations (predictable identifiers), and testing (reproducible fixtures). Choose v4 for general-purpose identifiers where randomness and unpredictability are desired. If you don't specifically need determinism, v4 is simpler and more widely used.
Can I create custom namespaces for UUID v5?
Yes! While RFC 4122 defines standard namespaces (DNS, URL, OID, X.500), you can create custom namespaces by generating a UUID v4 and using it as your namespace identifier. This is useful for application-specific naming contexts. However, using RFC 4122 standard namespaces is recommended when applicable, as they ensure global uniqueness and interoperability with other systems.
Are UUID v5 identifiers globally unique across systems?
Yes! UUID v5 achieves global uniqueness through the combination of standardized namespace UUIDs and collision-resistant SHA-1 hashing. As long as you use proper RFC 4122 namespaces, different organizations can independently generate UUIDs for the same name (e.g., "example.com") without conflicts, because namespace context ensures uniqueness. The determinism is local to namespace+name combinations, while global uniqueness is maintained through namespace isolation.