UUID / GUID Regex Patterns

A practical UUID regex or GUID regex validates 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 guide 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 in RegEx Visualizer, a browser regex tester from Tools Viewer with JavaScript, PCRE2 WASM, and Go RE2 WASM dialects, a Compare tab, 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 the i flag 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, a regex for GUID and 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 a regex 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 as id=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 the m flag 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 need g or m. In tools that support it, \A and \z may be stricter whole-string anchors, but those are not JavaScript tokens.

Version and variant bits

Some systems only need looks 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 as 8, 9, a, or b at 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 [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 \{?...\}? 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. \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: ^\d+$ or ^[0-9]+$.
• Regex only numbers in a larger string: \d+ with g.
• Regex for alphanumeric: ^[A-Za-z0-9]+$ for ASCII letters and digits.
• Regex for numeric with an optional decimal: start from ^\d+(\.\d+)?$ and tighten for signs, thousands separators, or locale rules.
• Hex only: ^[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 the g flag only when you need multiple matches in longer text.

C#, PowerShell, JavaScript, PCRE2, and RE2 notes

Searches like csharp regex match, powershell regex replace, and javascript uuid regex often mix regex behavior with string escaping. The UUID patterns above are deliberately simple, so JavaScript, PCRE2, and Go RE2 should agree on the core matches. The difference usually appears when you paste the pattern into a host language string, not when the regex engine evaluates the hex groups.

Use RegEx Visualizer's dialect controls and Compare tab to check JavaScript, PCRE2 WASM, and Go RE2 WASM against the same sample list. Exports and snippets can help with target-language ergonomics, but the browser tester is not a full .NET, PowerShell, PHP, or Go runtime. After the regex is correct, adapt slashes and string quoting for your actual codebase. See the regex tester online guide for a broader testing workflow.

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. Open RegEx 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. Toggle i if you use the shortened lowercase hex class.
6. Use g only when searching through longer text for every occurrence.
7. Open Compare to see JavaScript, PCRE2, and Go RE2 behavior on the same pattern.

FAQ

Related reading

• Regex cheat sheet
• Regex tester online
• Regex space & whitespace
• Regex newline
• RegEx Visualizer guide