UUID / GUID Regex Patterns You Can Copy

A practicalUUID regexorGUID regexvalidates the familiar 8-4-4-4-12 hexadecimal string used in APIs, logs, databases, tracing systems, and configuration files. Most searches for this topic want one of two things: find UUID-looking values inside text, or require an exact UUID match for a whole form field. Those are different regex jobs, and the anchors matter.

This article gives copy-paste patterns for the common UUID / GUID shape, exact match anchors, optional brace form, version and variant bits, digits-only regex, alphanumeric regex, and related validation choices. You can test the examples inRegEx Visualizer, a browser regex tester from Tools Viewer that matches with JavaScript RegExp, plus Replace mode and presets including UUID/GUID and Digits only. For core testing, your patterns and sample IDs stay on-device.

Quick answer: UUID / GUID regex

The common UUID string form is eight hexadecimal digits, a hyphen, four hex digits, a hyphen, four hex digits, a hyphen, four hex digits, a hyphen, and twelve hex digits. Use this pattern when you need to find UUID-looking strings in larger text:

[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}

Use theiflag if your engine supports case-insensitive matching and you want a shorter pattern:

[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}

For the common string form, aregex for GUIDand a regex for UUID are the same. Microsoft tools often say GUID, while many web APIs say UUID. Binary GUID byte ordering and database storage are separate topics; this article is about validating and finding the text representation.

Exact match anchors

For aregex exact match, wrap the pattern with anchors so the entire string must be the UUID. Without anchors, the regex can match a UUID substring inside a larger value such asid=550e8400-e29b-41d4-a716-446655440000;.

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

In JavaScript,^and$normally mean start and end of the string. With themflag they can also refer to line boundaries, so exact validation code should be clear about flags. If you are validating one input value, you usually do not needgorm. In tools that support it,{String.raw`\A`}and{String.raw`\z`}may be stricter whole-string anchors, but those are not JavaScript tokens.

Version and variant bits

Some systems only needlooks like a UUID. Others want to check RFC-style version and variant positions. The UUID version appears as the first character of the third group. The common RFC 4122 variant appears as8,9,a, orbat the start of the fourth group. For versions 1 through 5, use:

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-5][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}$

Modern systems may use version 6, 7, or 8 UUIDs, so a hardcoded{String.raw`[1-5]`}version check can reject valid IDs from newer generators. If your contract says UUIDv4 only, make that explicit:

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-4[0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}$

Use the looser 8-4-4-4-12 pattern for log search and import tools when the generator is unknown. Use the stricter version and variant pattern only when your product requirement names the allowed UUID versions.

Optional brace form

.NET, PowerShell, and some documentation examples show GUIDs wrapped in braces, such as{550e8400-e29b-41d4-a716-446655440000}. If your input should allow either the bare form or a matching pair of braces, use an alternation that keeps the pair balanced:

^(?:[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}|\{[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}\})$

A shorter pattern such as{String.raw`\{?...\}?`}may look tempting, but it also accepts an opening brace without a closing brace or a closing brace without an opening brace unless you add more logic. For validation, balanced forms are clearer. For searching messy logs, a looser finder can be acceptable if your downstream code cleans the result.

Hyphenless UUIDs and boundaries

Hyphenless 32-character hex strings appear in some systems. Decide whether your validator should accept them before adding the option. Any random 32 hex characters can look like a hyphenless UUID, so accepting this form may increase false positives in hashes, tokens, and binary dumps.

^[0-9a-fA-F]{32}$

When finding UUIDs inside text, consider boundaries.{String.raw`\b`}often works around hyphenated UUIDs because the first and last characters are hex word characters, but boundaries can be subtle near underscores and non-ASCII text. If false positives matter, test examples where the UUID is adjacent to letters, digits, underscores, quotes, braces, and punctuation.

Digits only and alphanumeric regex

Related validation patterns often appear next to UUID checks in forms and APIs. They are not UUID patterns, but they use the same exact-match idea: anchor the whole string when you are validating a field, and omit anchors when you are searching inside text.

• Regex for digits only:{String.raw`^\d+$`}or{String.raw`^[0-9]+$`}.
• Regex only numbersin a larger string:{String.raw`\d+`}withg.
• Regex for alphanumeric:{String.raw`^[A-Za-z0-9]+$`}for ASCII letters and digits.
• Regex for numericwith an optional decimal: start from{String.raw`^\d+(\.\d+)?$`}and tighten for signs, thousands separators, or locale rules.
• Hex only:{String.raw`^[0-9a-fA-F]+$`}, useful when validating one UUID group or a compact token.

RegEx Visualizer includes a Digits only preset, so you can switch from UUID validation to simpler field validation without rebuilding the setup. The same workflow applies: paste valid and invalid examples, use exact anchors for whole-field validation, and add thegflag only when you need multiple matches in longer text.

C#, PowerShell, and JavaScript quoting notes

Searches likecsharp regex match,powershell regex replace, andjavascript uuid regexoften mix regex behavior with string escaping. The UUID patterns above are deliberately simple, so the core hex groups usually transfer cleanly once quoting is correct. Differences usually appear when you paste the pattern into a host language string, not in the hex group logic itself.

RegEx Visualizer matches with JavaScript RegExp. Export snippets for C#, PowerShell, and other hosts are copy-paste helpers for string quoting and API shape — they are not alternate match engines or full.NET / PowerShell runtimes. After the pattern is correct in the browser, adapt slashes and quoting for your actual codebase.

Test with realistic valid and invalid IDs

A UUID regex is easy to over-trust if you test only one perfect example. Include lowercase, uppercase, invalid hex letters, missing groups, extra hyphens, leading and trailing spaces, brace-wrapped values, and UUIDs embedded in longer lines. If your app trims user input before validation, test both the raw and trimmed versions. If your app stores UUIDs in a database, compare the exact text form your API returns.

Use Replace mode for extraction tasks. For example, you can find UUIDs in a log and replace them with[uuid]to sanitize examples before sharing. Because the core test runs in the browser, this is a convenient way to inspect private sample text without uploading it to a server-side regex tool.

Try it in RegEx Visualizer

1. OpenRegEx Visualizer.
2. Choose the UUID/GUID preset.
3. Add valid UUIDs, invalid IDs, uppercase examples, and a brace-wrapped GUID.
4. Add^and$when you need whole-string validation.
5. Toggleiif you use the shortened lowercase hex class.
6. Usegonly when searching through longer text for every occurrence.