UUID v5 / v3 Generator

Name-based UUIDs: a deterministic identifier derived from a namespace and a name. The same inputs always produce the same UUID — useful when you need stable IDs without a central allocator.

Hash algorithm

Same (namespace, name) always produces the same UUID — that's the point of v5/v3.

Output options
Case
Bulk delimiter
Enter name(s) and click Generate.

About namespace UUIDs

Namespace UUIDs (versions 3 and 5) solve a problem distinct from the random UUIDs most people are familiar with: they produce the same output every time when given the same input. This determinism is the entire point. Instead of asking "give me a new unique identifier," you're asking "give me the identifier for this particular thing."

The mechanism is straightforward. You provide a namespace (itself a UUID, chosen to identify the domain you're working in) and a name (a string within that domain). The generator concatenates them, hashes the result with MD5 (for v3) or SHA-1 (for v5), and formats the hash into the UUID structure. Anyone, anywhere, given the same namespace and name will produce the same UUID. No coordination required.

This makes namespace UUIDs ideal for situations where you need stable identifiers derived from data that already exists. Common patterns include:

  • Generating IDs from URLs, so the same URL always maps to the same UUID across systems;
  • Creating consistent IDs from external keys during system integration, so two services agree on the identity of a record without needing to negotiate a shared mapping;
  • Deduplicating records by content, where the same content should always produce the same identifier regardless of when it's processed;
  • Producing stable references for hierarchical data, such as the path of a file within a tree.

v5 vs v3 — which should I use?

v5 (SHA-1) supersedes v3 (MD5). Both versions produce a UUID by hashing namespace_bytes || utf8(name) and forcing the version and variant bits. The only meaningful difference is the hash function — and SHA-1 has been the preferred choice since RFC 4122 in 2005.

Use v5 for any new system. RFC 9562 explicitly recommends it. It also gives you a tiny bit more collision resistance — SHA-1 is broken for adversarial collisions, but the 122 effective bits of a v5 UUID are random enough that incidental collisions remain astronomically unlikely.

Use v3 only when you need to reproduce existing v3 identifiers — e.g., interoperating with a legacy system that already issued v3 UUIDs. There is no scenario where v3 is the right choice for a new ID.

When to use name-based UUIDs at all

  • Stable IDs from natural keys. "Give me the UUID for company.com" returns the same value forever, across machines, without coordination.
  • Idempotent record creation. Derive a UUID from your input payload; re-runs of the same job produce the same ID and naturally upsert.
  • Cross-system joins. Two services that derive UUIDs from the same canonical name will agree on the identifier without exchanging it.
  • Not for anything random or unguessable — v5 of a known name is reproducible by anyone with that name. Use v4 if you need unpredictability.

Choosing a namespace

RFC 9562 §6.6 defines four standard namespaces:

  • DNS   6ba7b810-9dad-11d1-80b4-00c04fd430c8 — for fully-qualified domain names
  • URL   6ba7b811-9dad-11d1-80b4-00c04fd430c8 — for URLs
  • OID   6ba7b812-9dad-11d1-80b4-00c04fd430c8 — for ISO object identifiers
  • X.500 6ba7b814-9dad-11d1-80b4-00c04fd430c8 — for X.500 distinguished names

For application-specific data — internal entity types, tenant identifiers, custom record keys — generate a fresh UUID once (a v4 will do) and use that as your custom namespace. Document the namespace somewhere persistent so your team and any integrators can produce matching IDs. Treat it like a schema version: changing the namespace later means all your derived IDs change too.

What namespace UUIDs are not for

Namespace UUIDs are identifiers, not secrets. Anyone who knows the namespace and the name can produce the UUID. This makes them unsuitable as:

  • Session tokens or authentication credentials;
  • API keys or shared secrets;
  • Anti-enumeration identifiers (where you want IDs to be unguessable from external information).

If you need an identifier whose value cannot be predicted by someone who knows the underlying data, use UUID v4, a NanoID with sufficient length, or a purpose-built random token.

Generating in code

C#

using System.Security.Cryptography;
using System.Text;

static Guid Uuid5(Guid ns, string name)
{
    Span<byte> nsBytes = stackalloc byte[16];
    ns.TryWriteBytes(nsBytes, bigEndian: true, out _);
    var input = new byte[16 + Encoding.UTF8.GetByteCount(name)];
    nsBytes.CopyTo(input);
    Encoding.UTF8.GetBytes(name, input.AsSpan(16));
    var hash = SHA1.HashData(input);
    var uuid = hash.AsSpan(0, 16).ToArray();
    uuid[6] = (byte)((uuid[6] & 0x0F) | 0x50);
    uuid[8] = (byte)((uuid[8] & 0x3F) | 0x80);
    return new Guid(uuid, bigEndian: true);
}

Python

import uuid
id = uuid.uuid5(uuid.NAMESPACE_DNS, "www.example.com")
# 2ed6657d-e927-568b-95e1-2665a8aea6a2

FAQ

When should I use a namespace UUID?
When you need a stable identifier derived from existing data without coordinating across systems. Common cases: generating an ID from a URL (so the same URL always maps to the same ID), deriving IDs from external keys during integrations, and content-addressed deduplication. Two systems hashing the same name in the same namespace agree on the result without ever exchanging it.
Are namespace UUIDs secure?
No — and they're not designed to be. Anyone who knows the namespace and name can reproduce the UUID. Treat them as identifiers, not credentials: don't use them as session tokens, password-reset links, or anything else that relies on unpredictability. For unguessable IDs, use v4.
Is v5 vulnerable because SHA-1 is broken?
No. SHA-1 is broken for adversarial collision resistance — attackers can craft two different inputs that hash to the same value. For v5 to be a problem, you would need to be using it as a security primitive, which it isn't. As an identifier, the relevant property is that random inputs don't collide, and that's still true with overwhelming probability.
Is MD5 in UUID v3 a problem?
MD5 is cryptographically broken for adversarial collision resistance, but v3 isn't a security primitive — its job is deterministic ID generation, where MD5's incidental collision resistance is more than adequate. The reason to prefer v5 is just that it's the spec-recommended successor; there's no scenario where v3 is the better engineering choice for new work.
Will the same name always produce the same UUID?
Yes, provided the namespace, name, and version are the same. That's the entire point — v5/v3 are deterministic. Different namespaces with the same name produce different UUIDs, and so do different versions.
Can I use a v4 UUID as my custom namespace?
Yes — and that's the recommended way to mint a private namespace. Generate a v4 once, document it, then use it as the namespace seed for every v5/v3 UUID in that domain.
Why does v5 truncate the SHA-1 hash?
SHA-1 produces 20 bytes; a UUID is 16 bytes. RFC 9562 says to use the first 16 bytes and then overwrite 6 bits with the version (4) and variant (2) markers. Effective randomness: 122 bits — same as v4.
An unhandled error has occurred. Reload ×