UUID v5 Generator

Every time your application needs a stable, reproducible identifier tied to a meaningful name — a domain, a URL, a resource path — a UUID v5 generator gives you exactly that: a fixed, predictable UUID derived from a namespace and a name string. Unlike a randomly generated value that changes on every call, a version 5 UUID always returns the same output for the same inputs, so you get a consistent, collision-resistant identifier with no mapping table to maintain.

How the Namespace and Name Inputs Work

The generator above requires two inputs: a namespace UUID and an arbitrary name string. Together they feed a SHA-1 hash, producing a stable 128-bit identifier every time — no randomness, no surprises. RFC 4122 predefines four standard namespaces: For Node.js and Python PyMongo UUID patterns, the mongodb uuid guide has complete driver-specific examples.

• DNS — use when your name is a domain, such as example.com
• URL — for full URL strings
• OID — for ASN.1 object identifiers, common in X.509 certificates
• X.500 DN — for LDAP distinguished names

You can also supply any UUID of your own as a custom namespace — useful for scoping IDs to your own application or entity type. Once you generate, the result appears in standard format: 32 hex characters in five hyphenated groups (8-4-4-4-12), 36 characters total.

How UUID v5 Generation Works

UUID v5 is a name-based scheme built on SHA-1, a cryptographic hash producing a 160-bit (20-byte) digest from any input. Generation takes the first 128 bits of that digest and stamps in the version and variant markers:

UUID NameToUUID(UUID namespace, String name) {
    // Concatenate namespace bytes and name bytes
    byte[] input = namespace.toBytes() + name.toBytes();

    // Compute SHA-1 -- produces 20 bytes (160 bits)
    byte[] hash = SHA1(input);

    // Copy first 16 bytes into result UUID
    byte[] result = hash[0..15];

    // Stamp version 5 into the high nibble of byte 6
    result[6] = (result[6] & 0x0F) | 0x50;

    // Stamp the RFC 4122 variant into byte 8
    result[8] = (result[8] & 0x3F) | 0x80;

    return result;
}

This is the canonical sequence used by every conforming implementation, whether in a software library or a command-line tool. It's a pure, one-way function — given only the output UUID, you cannot reverse the SHA-1 to recover the original name, which makes v5 a safe choice for internal naming schemes where the source shouldn't be exposed.

UUID v5 vs UUID v3, v4, and v1

• UUID v1 — generated from the host timestamp and MAC address; sortable but not suitable when hardware privacy matters
• UUID v3 — identical structure to v5 but uses MD5 instead of SHA-1; RFC 4122 recommends v5 over v3 for all new applications since MD5 is cryptographically weaker
• UUID v4 — fully random, no namespace, no name, no reproducibility; every call produces a different value
• UUID v5 (this tool) — SHA-1 over a namespace and name pair; always consistent, never randomly generated

When to Use UUID v5

Reach for a name-based UUID whenever you need a persistent token for a resource that already has a canonical name: The fastest way to generate uuid v4 is to use the browser-based UUID v4 Generator — no sign-up required.

• Records with natural keys — generate the same ID for the same domain object without a separate ID column, e.g. hashing a REST resource path under the URL namespace
• Distributed systems — multiple nodes assign the same label to the same logical entity with no coordination needed
• Merging datasets — independent systems hashing the same name under the same namespace arrive at identical UUIDs, eliminating reconciliation work
• Idempotent message IDs — hash a topic name and message key to get a fixed ID that deduplicates across retries

For a completely anonymous, non-reproducible token — session values, temporary objects, anything where revealing the name structure would be a privacy risk — use UUID v4 instead.

Frequently Asked Questions