The Regex Conditions Needed to Correctly Pick UUIDs Out of Text
When you use a tool that pulls UUIDs out of a log file or a JSON response, it's tempting to assume that just checking for "a 32-character hex string in the 8-4-4-4-12 shape, hyphen-separated" is enough — but in practice, it isn't. A hyphen-delimited, 32-character hex string can perfectly well come from something that isn't a UUID at all, purely by coincidence. This guide looks at how far a regex actually needs to validate to match UUIDs correctly, and checks how the real tool's code implements that.
1. Why a Shape-Only Regex Gives False Positives
A UUID's outward appearance is simple: a 36-character hex string (including 4 hyphens) split into groups of 8, 4, 4, 4, and 12 digits, hyphen-separated. The problem is that this shape by itself isn't unique to UUIDs. An arbitrary hash value chopped up and hyphenated, or a random hex string generated as test data, can easily end up with the exact same digit grouping purely by chance. A regex that only checks the shape (for example, [0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}) will misidentify all of these as "UUIDs" too.
2. Two Hidden Validation Positions Baked Into the UUID Spec
The RFC 4122 standard fixes two specific positions among a UUID's 36 characters to a restricted set of values. The 3rd group's first character (the 13th character overall) is the version field, which can only be a digit from 1 to 5. The 4th group's first character (the 19th character overall) is the variant bits, which can only be one of 8, 9, a, or b — the marker for the standard variant (the RFC 4122 layout). These two positions are constraints that any algorithm generating a real UUID must obey, so a genuine UUID will always satisfy them. Put the other way around, a string that violates either of these two positions cannot be a real UUID — and a regex that validates these two positions as well can cut its false-positive rate dramatically.
3. What UUID Versions 1 Through 5 Actually Mean
The version field isn't just a number for validation purposes — it tells you how the UUID was actually generated. v1 is based on a timestamp plus a MAC address; v3 and v5 are name(namespace)-based hashes (MD5 and SHA-1, respectively); and v4 is fully random generation, which is by far the most widely used method today. v2 is the DCE-security version and is rarely used in practice. If the version-field position holds a value outside the 1–5 range — say 6, 7, or 0 — that's a value no standard UUID-generation algorithm can ever produce, which means that string is very likely not a UUID at all, just some other hex data that happens to share the shape.
4. Breaking Down MODOO HUB's UUID Extractor Regex
Checking the actual source code of the UUID extractor, it uses the following regex.
/[0-9a-f]{8}-[0-9a-f]{4}-[1-5][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}/giThe 3rd group is explicitly constrained to start with
[1-5], and the 4th group is explicitly constrained to start with [89ab] — so this isn't a plain shape match, it's implemented to validate the version and variant positions as well.
In other words, this tool is designed to recognize as a UUID only strings that actually satisfy the RFC 4122 spec, rather than any hex string that merely "looks plausible."
5. Strings That Share the Shape but Aren't Real UUIDs
The table below shows examples of strings that look like UUIDs at a glance but get filtered out in practice because they fail the version/variant conditions.
| String | 8-4-4-4-12 shape | Version position (13th char) | Variant position (19th char) | Recognized as UUID |
|---|---|---|---|---|
| 550e8400-e29b-41d4-a716-446655440000 | Matches | 4 (valid) | a (valid) | Recognized |
| 12345678-1234-6789-1234-123456789012 | Matches | 6 (out of range) | 1 (out of range) | Rejected |
| ffffffff-ffff-ffff-ffff-ffffffffffff | Matches | f (out of range) | f (out of range) | Rejected |
The second and third strings have exactly the same hyphen structure and hex digit count as a real UUID, but their version and variant positions fall outside the spec, so they can't actually be UUIDs. A tool that only checks shape would misidentify all three as UUIDs, but a regex that also validates version and variant correctly picks out only the first one. If you're trying to filter true UUIDs out of text mixed with hash values or arbitrary tokens, this difference matters quite a bit in practice.
6. How to Test It Yourself
The quickest way to check whether a tool only checks shape or also validates version and variant is to just try it. Paste the second string from the table above (12345678-1234-6789-1234-123456789012) into the UUID extractor — if it doesn't show up in the extraction results, that tool's regex includes version/variant validation. If it does get counted as a UUID, that's a sign the regex is loose and only checks shape.
Frequently Asked Questions
Q. If the version field isn't 1–5, is it automatically a fake UUID?
It means a standard UUID-generation algorithm (v1 through v5) couldn't have produced that value. That said, an identifier someone manually crafted to "look like a UUID" might violate this condition while still being a valid identifier of some other kind in practice — so the more precise way to put it is "not a standard RFC 4122 UUID."
Q. Does it recognize 32-character UUIDs without hyphens?
MODOO HUB's UUID extractor's current regex only matches the hyphen-separated 8-4-4-4-12 format. A continuous 32-character hex string with the hyphens stripped out is not recognized.
Q. Are newer UUID versions like v6 or v7 recognized too?
The current regex restricts the version position to 1–5, so v6 and v7 UUIDs — formats that are still in the process of being standardized — get rejected at the version-position check and aren't recognized.
Q. Are uppercase UUIDs extracted too?
Yes. The regex applies the case-insensitive (i) flag, so uppercase UUIDs are recognized the same way, and turning on the "normalize to lowercase" option will display the results in lowercase uniformly.