UUID v5 Generator
UUID v5 generator to create a UUID from a string online in seconds. Enter a namespace and a name, and the tool will generate UUIDv5 values, also known as uuid5 or UUID 5, that you can copy into your project. Every v5 UUID is built by hashing the namespace and name with SHA-1, so the same inputs always return the same ID, which makes this UUID5 generator ideal for stable, repeatable identifiers.
Shortcuts: C copy · R generate · G generate bulk
Looking for a UUID 5 generator or a UUID version 5 generator? This online UUID generator from string gives you an online UUID from string, whether you need uuid5 online or uuidv5 online.
What Is UUID v5?
UUID v5 is a name-based UUID defined in RFC 9562. Instead of using random or time-based data, it is generated from a namespace UUID and a name. That makes it a deterministic UUID: the same namespace and name always produce the same result. If you are wondering whether a UUID is deterministic, version 5 is, unlike v4, which is random. You may also see it called UUID 5 or a deterministic GUID, since GUID is Microsoft’s name for the same 128-bit identifier.
UUID v5 Example and Format
Here is a valid UUID v5, generated from the DNS namespace and the name python.org:
886313e1-3b8a-5372-9b90-0c9aee199e5d
Every v5 UUID follows the standard 8-4-4-4-12 layout: 32 hexadecimal digits split into five groups by four hyphens, 36 characters in total. Two characters tell you what kind of UUID it is:
- Version: the first digit of the third group is always 5. In the example, that group is 5372.
- Variant: the first digit of the fourth group is 8, 9, a, or b. In the example, that group is 9b90.
If you need to check whether a v5 UUID is valid, look at these two positions first. A GUID UUIDv5 uses the same text format, because a GUID is simply the Microsoft term for a UUID. Both are 128-bit identifiers and follow the same standard string layout.
How UUID v5 Works
- Take the 16 bytes of the namespace UUID.
- Append the bytes of the name (usually encoded as UTF-8).
- Hash the combined bytes with SHA-1, which gives a 160-bit result.
- Keep the first 128 bits.
- Set the version bits to 5 and the variant bits to the standard value.
- Write the result in the 8-4-4-4-12 format.
Because nothing random is involved, the output is a deterministic UUID. Two systems that use the same namespace and name will independently generate the same ID, with no shared database or coordination. This UUID deterministic behavior is the main reason to choose v5 over v4. Change either the namespace or the name, and you get a different UUID. The hash can’t be reversed to recover the name, but v5 is meant for stable identifiers, not for secrets.
How to Generate a UUID from a String
With UUID v5, the string you type is the name input, but the output depends on two values: the namespace and the name. A string alone does not decide the result. Use the tool above to generate a UUID from a string online: choose a namespace, enter your string, and copy the result. It is the quickest way to create a UUID from a string online without writing code.
- Select a namespace UUID, or paste your own.
- Enter the string as the name.
- Generate the UUID.
- Copy the result.
The same steps let you create a UUID from a string, generate a UUID from string values such as URLs or email addresses, or get a UUID from a name for any record that needs a stable ID. This UUID generator from string can also generate a unique ID from string input, create a unique ID from string input, or create a unique identifier from string input. For a unique ID from a string that stays the same across systems, use the same namespace every time. To get the same UUID from string input again, keep the string identical, including case and spaces. Changing one character gives a different UUID. A UUID from an online tool and a UUID from a string function in your code will match as long as they use the same namespace and name.
“Unique” here means that different names in the same namespace give different UUIDs, with collisions extremely unlikely. Two identical strings in the same namespace always give the same UUID, by design.
UUID v5 Namespace and Name Inputs
A namespace UUID is a fixed UUID that sets the context for the name. The same string in two different namespaces produces two different UUIDs, so the namespace keeps IDs from different systems apart. The name is the string you want to identify, such as a domain, a URL, or a username.
RFC 4122, titled “A Universally Unique Identifier (UUID) URN Namespace”, first defined four standard namespaces. RFC 9562 has since replaced it and keeps them. The “URN namespace” in that title refers to the urn:uuid: format used to write UUIDs as URNs. It is a different thing from the namespace UUID you choose for v5. In short, a universally unique identifier UUID URN namespace is how UUIDs are written as URNs, while the namespace input is a UUID that scopes your names.
|
Namespace |
UUID |
Use it for |
|
DNS |
6ba7b810-9dad-11d1-80b4-00c04fd430c8 |
Domain names |
|
URL |
6ba7b811-9dad-11d1-80b4-00c04fd430c8 |
Full URLs |
|
OID |
6ba7b812-9dad-11d1-80b4-00c04fd430c8 |
ISO OIDs |
|
X.500 |
6ba7b814-9dad-11d1-80b4-00c04fd430c8 |
X.500 DNS |
The UUID namespace URL is the second row. In Python, these appear as uuid.NAMESPACE_URL and uuid.NAMESPACE_DNS. If none of the standard namespaces fit, generate your own UUID once and reuse it as your application’s namespace.
Deterministic UUID Generation
A conforming UUID v5 implementation returns the same result for the same namespace and name. That is what lets you generate deterministic UUID values on any system. A deterministic GUID or deterministic UUID is easy to reproduce in tests, data migrations, and deduplication, and UUID deterministic generation needs no stored state or shared database.
Can you set a seed for UUID? Not for v5 in the usual sense, because v5 uses no random number generator. The namespace and name are fixed inputs, not a random seed. If you searched for a UUID generator seed, UUID seed, or UUID from seed, the closest equivalent in v5 is choosing one fixed namespace and one fixed name. Seeding applies to random generators, which is a separate topic.
UUID Namespaces Explained
A namespace UUID is a fixed UUID that defines the context in which names are interpreted. UUID v5 combines it with a name, so the same name gives a different UUID in each namespace. This is why a namespaced UUID stays unique across systems: two applications can use the same string, such as users/1001, and still get different IDs as long as they use different namespaces. UUID v3 works the same way and differs only in using MD5 instead of SHA-1.
The same idea applies to a GUID namespace. A GUID is the Microsoft name for a UUID, so a GUID namespace is simply a namespace UUID used when you generate GUIDs from names. The format and the rules don’t change.
RFC 9562 defines four standard namespaces:
- DNS: for fully qualified domain names
- URL: for URLs
- OID: for ISO object identifiers
- X.500: for X.500 distinguished names
Each one is a predefined UUID, so any system that picks the same one will generate the same results. When none fits your data, create your own namespace UUID once (a random v4 works well), store it in your configuration, and reuse it every time. A good namespace for UUIDs in your own app is one value per kind of data, for example, one for users and one for orders. Changing the namespace later changes every ID you generate.
The namespace and the name together decide the output. The same namespace and name always give the same UUID. A different namespace or a different name gives a different one.
UUID v5 vs. UUID v4 and UUID v3
UUID v5, v4, and v3 are all 128-bit identifiers in the same 8-4-4-4-12 format. They differ in how the value is made. v4 uses random data, while v3 and v5 are name-based and take a namespace UUID and a name. You can tell them apart by the first digit of the third group, which is 3, 4, or 5.
|
UUID v3 |
UUID v4 |
UUID v5 |
|
|
Generated from |
Namespace + name |
Random data |
Namespace + name |
|
Algorithm |
MD5 |
Random or pseudorandom number generator |
SHA-1 |
|
Deterministic |
Yes |
No |
Yes |
|
Same input gives same UUID |
Yes |
No |
Yes |
|
Version digit |
3 |
4 |
5 |
UUID v5 vs. UUID v4
UUID v5 is a deterministic UUID. The same namespace and name always give the same result, on any system, with no stored state. UUID v4 is the opposite. It is built from random or pseudorandom bits, so generating it twice gives two different values, and you cannot get the same UUID from a string.
This decides which one fits your use case:
- Choose v5 when you need to create a UUID from a string and get the same ID every time: mapping a URL, domain, or email to a stable ID, deduplicating records, or producing matching IDs across systems and migrations.
- Choose v4 when each record should get a new, unrelated ID, such as database rows, sessions, or requests, and nothing about the ID should be derivable from its content.
One practical difference: a v5 UUID can be regenerated by anyone who knows the namespace and the name, so it is not a secret and shouldn’t be used as one. A v4 UUID has no input to guess, but it is still an identifier, not a security token.
UUID v5 vs. UUID v3
UUID v3 and UUID v5 are the two name-based versions, and they work the same way: the namespace UUID and the name are combined and hashed, and the result is formatted as a UUID. The only difference is the hashing algorithm. v3 uses MD5, and v5 uses SHA-1. Both are deterministic, both accept the same four standard namespaces (DNS, URL, OID, and X.500), and for the same inputs they give different UUIDs, since the hash differs.
How to choose:
- Choose v5 for new work. It is the more current of the two, and RFC 9562 recommends it over v3 unless you need compatibility with existing v3 IDs.
- Choose v3 only when you must match IDs that were already generated with v3, for example, in a legacy system.
- Don’t mix them for the same data. A v3 UUID and a v5 UUID generated from the same namespace and name are not equal, so switching versions changes every ID.
MD5 and SHA-1 are both considered weak for security uses, but that doesn’t affect these versions much, because UUIDs are used as identifiers, not for authentication or signatures.
UUID v5 Uniqueness and Collision Considerations
The same namespace and the same name always produce the same UUID. That is intentional, and it is what makes UUID v5 a deterministic UUID. Repeated output from identical input is not a collision. It is the behavior you chose when you picked a name-based version.
Will I get the same UUID with the same namespace? Yes, if the name is also identical. The namespace alone does not fix the result, because the name is the second input. Use the same namespace with a different name, and you get a different UUID. Use the same name in a different namespace, and you also get a different UUID. The name must match exactly. A different case, an extra space, or a different text encoding is a different name, so it gives a different UUID.
Why aren’t namespaced UUIDs unique? They are unique per distinct namespace and name pair, but not per generation request. Two requests with the same pair return the same value, and that is why a namespaced UUID cannot be treated as a fresh ID each time. If every record needs its own ID regardless of content, use UUID v4 instead, as covered in the comparison section above.
UUID v5 collision is a separate question: can two different inputs produce the same UUID? In theory, yes. A UUID v5 has 122 bits that come from the hash (6 of the 128 bits are reserved for the version and variant), and any hash that maps unlimited inputs into a fixed-size output allows two inputs to share an output. In practice, for ordinary data such as URLs, domains and usernames, an accidental UUID v5 collision is extremely unlikely, at the same practical level as random UUID v4 values. Still, no source can promise absolute uniqueness, and neither should your documentation.
Keep these points in mind:
- Keep names distinct: two different records that share one name in one namespace will get the same UUID. Make sure the name you hash really identifies the record.
- Use one namespace per kind of data: this stops equal names in different systems from being treated as the same thing.
- Avoid untrusted names where uniqueness matters: v5 uses SHA-1, which has known collision attacks. If outsiders can choose the name, they may be able to craft inputs on purpose, so don’t use v5 for security decisions. For random, unguessable IDs, use v4.
UUID v5 Use Cases and Limitations
UUID v5 is a good fit when an ID must be rebuilt from the data itself, and a poor fit when an ID must be unpredictable. The sections below cover both sides.
UUID v5 Use Cases
- Repeatable identifiers for names or strings: create a UUID from a string such as a URL, domain, email address, or product code, and get the same UUID from the string every time it is generated. The same namespace and the same name always return the same ID.
- Stable identifiers across compatible implementations: any conforming UUID v5 implementation, in any language, returns the same result for the same namespace and name. Two services can generate the same deterministic UUID independently, with no shared database or coordination. This is also why people look for implementations by searching terms like “uuidv5 GitHub”. Those are code libraries, and the generator on this page gives the same output as a conforming one.
- Deduplication and migrations: records that describe the same thing map to the same ID, so re-importing data does not create duplicates.
When UUID v5 Is More Suitable Than Random UUID Generation
Choose UUID v5 over random generation when the ID has to be derived from content and be reproducible. Random UUID v4 values are different on every run, so they cannot be recreated from a name. UUID v5 can. If every record just needs its own new ID and nothing should be derivable from its content, v4 is the better choice. The comparison section above covers v3 and v4 in more detail.
UUID v5 Limitations
UUID v5 is not a cryptographic token or a secret generator, so don’t use it that way. If you came here looking for a token generator uuid5 for sessions, API keys, password resets, or access tokens, this is not the right tool. These reasons apply:
- It is predictable by design. Anyone who knows the namespace and the name can regenerate the UUID, and the standard namespaces are public. An attacker who guesses the name gets the ID.
- It uses SHA-1. The hash is fine for identifiers, but SHA-1 has known collision attacks, so don’t use v5 where outsiders control the name and a collision would matter for security.
- It is not unique per request. The same input gives the same output, so it can’t serve as a one-time value.
For tokens and secrets, use a cryptographically secure random generator and keep the value private. UUID v5 is for identifiers, not for authentication.