DevbeltDevbeltAll tools
Devbelt

UUID v5 Generator

Deterministic, namespace-based UUIDs (SHA-1)

GENERATED
Click Generate.
INSPECT ANY UUID

Paste a UUID above, or generate one on the left, to see what's inside it.

Every UUID is generated and decoded in your browser using Web Crypto. Nothing is ever uploaded or stored on a server.

About

Every other version on this site is random: run it twice and you get two different UUIDs. Version 5 is the opposite on purpose. It hashes a namespace and a name together with SHA-1, so the exact same namespace and name always produce the exact same UUID, every time, on any machine, with no database lookup required. That's useful whenever you need a stable ID for something you'll see again, like turning a URL or a filename into a consistent identifier without maintaining a mapping table.

What makes v5 deterministic

A v5 UUID is built from SHA-1(namespace bytes + name bytes), with a few bits overwritten afterward to mark the version and variant. Since a hash function always produces the same output for the same input, feeding it the same namespace and name always gives you the same UUID back. That's the entire mechanism, there's no randomness involved anywhere in the process.

SHA-1( DNS-namespace + "example.com" )
  → always → cfbff0d1-9375-5685-968c-48ce8b15ae17

Choosing a namespace

The namespace exists so the same name doesn't collide across different contexts, hashing "example.com" as a DNS name should give a different UUID than hashing the literal string "example.com" for some other purpose. RFC 4122 defines four standard namespaces:

  • DNS — for domain names
  • URL — for full URLs
  • OID — for ISO object identifiers
  • X.500 — for X.500 distinguished names

None of them fit, that's fine too. Pick Custom namespace and use any UUID you like, including one you generated yourself, as your own private namespace. As long as you reuse that same namespace UUID consistently, your generated IDs stay deterministic within your own system.

Why SHA-1 here isn't a security concern

SHA-1 is considered broken for security purposes like certificate signing, where an attacker deliberately engineering two different inputs to collide is a real threat. That's not the situation here. v5 uses SHA-1 purely as a deterministic mixing function to turn a name into a well-distributed 128-bit value, not to protect against anyone trying to forge a collision. The RFC itself specifies SHA-1 for exactly this reason, and it remains the correct, standards-compliant choice for name-based UUIDs.

Frequently asked questions

What is a UUID v5 used for?
Anywhere you need a stable, repeatable ID derived from something you already have, like a URL, a filename, or an external system's ID, without maintaining a separate lookup table. Hash the same input twice and you get the same UUID both times.
Why does the same input always give the same UUID?
Because v5 is built entirely from a SHA-1 hash of the namespace and name, with no random component. A hash function is deterministic: the same bytes in always produce the same bytes out.
Is SHA-1 safe to use for this?
Yes. SHA-1's known weaknesses are about deliberate collision attacks in security contexts like certificates. Here it's just a mixing function for turning a name into a UUID, which is exactly what RFC 4122 specifies it for.
What if none of the standard namespaces fit my use case?
Use Custom namespace and supply any UUID, including one you generate yourself as a dedicated namespace for your application. Keep using that same namespace UUID and your generated IDs stay consistent.
What's the difference between v3 and v5?
They work identically, a hash of a namespace and a name, but v3 uses MD5 and v5 uses SHA-1. RFC 4122 recommends v5 over v3 wherever possible, which is why only v5 is offered here.

Related tools

UUID v4 GeneratorUUID v7 GeneratorUUID v1 Generator