GUID Regex Patterns - Validation & Best Practices

Common regex patterns for validating GUID / UUID input. Learn about canonical, versioned, and flexible regexes for input validation, plus practical examples in C#, Java, Python, JavaScript, and TypeScript.

Important: Regex can validate the format, but it cannot guarantee uniqueness, security or that a GUID / UUID was generated correctly. For strict validation, always parse using a trusted library.

Canonical GUID / UUID (hyphenated)

Matches the standard 8-4-4-4-12 representation with hex digits (case-insensitive).

^[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}$

Canonical + version (1-8) + RFC variant (8/9/a/b)

Enforces that the GUID / UUID is one of the modern versions (1 through 8) and uses the standard RFC variant (8, 9, a, or b).

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

Accept common input variants (braces and URN)

Accepts any of these forms: uuid, {uuid}, or urn:uuid:uuid. Useful for UI input fields where users paste different styles.

^(?:urn:uuid:)?(?:\{[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})$

Empty GUID / Nil UUID (all zeros)

Sometimes you want to explicitly detect an Empty GUID / Nil UUID.

^00000000-0000-0000-0000-000000000000$

Validation examples by language

The regex logic can stay the same across languages, but escaping, flags, and parser APIs differ. Use regex for quick format checks, then parse with a platform-specific UUID or GUID API when you need stricter validation.

C# example

using System;
using System.Text.RegularExpressions;

string pattern = @"^[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}$";
string input = "550e8400-e29b-41d4-a716-446655440000";

bool matches = Regex.IsMatch(input, pattern);
bool parsed = Guid.TryParse(input, out _);

Console.WriteLine($"Regex match: {matches}");
Console.WriteLine($"GUID parse: {parsed}");

In .NET, use Guid.TryParse() after the regex check when the value comes from user input or another external system.

Java example

import java.util.UUID;
import java.util.regex.Pattern;

String pattern = "^[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}$";
String input = "550e8400-e29b-41d4-a716-446655440000";

boolean matches = Pattern.matches(pattern, input);

try {
    UUID.fromString(input);
    System.out.println("UUID parse: true");
} catch (IllegalArgumentException ex) {
    System.out.println("UUID parse: false");
}

System.out.println("Regex match: " + matches);

Java regex can validate the string shape, but UUID.fromString() is the stronger final check for canonical UUID input.

Python example

import re
import uuid

pattern = r"^[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}$"
value = "550e8400-e29b-41d4-a716-446655440000"

matches = re.fullmatch(pattern, value) is not None

try:
    uuid.UUID(value)
    parsed = True
except ValueError:
    parsed = False

print(f"Regex match: {matches}")
print(f"UUID parse: {parsed}")

In Python, re.fullmatch() is the clearest regex choice for whole-string validation, and uuid.UUID(...) is the stricter parser check.

JavaScript example

const pattern = /^[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}$/;
const input = '550e8400-e29b-41d4-a716-446655440000';

const matches = pattern.test(input);

console.log(`Regex match: ${matches}`);
// For strict parsing, follow up with a trusted UUID library in app code.

JavaScript has straightforward regex support, but it does not provide a built-in UUID parser comparable to Guid.TryParse() or uuid.UUID(...). For strict validation, use a trusted UUID library after the regex check.

TypeScript example

const guidRegex = /^[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}$/;

function isCanonicalUuid(value: string): boolean {
    return guidRegex.test(value);
}

const input = '550e8400-e29b-41d4-a716-446655440000';
console.log(isCanonicalUuid(input));

TypeScript uses the same runtime regex engine as JavaScript. The main benefit is typed validation helpers, not different UUID parsing behavior.

Practical notes

  • Normalize first: trim whitespace, optionally strip urn:uuid: and braces, then validate.
  • Prefer parsing in code: use Guid.TryParse in C#, UUID.fromString in Java, uuid.UUID in Python, and a trusted UUID library in JavaScript or TypeScript after regex checks.
  • Version and variant are separate: version is the first hex digit of the third group; variant is the first hex digit of the fourth group.
  • Don't over-constrain input: if your app accepts uppercase or braces, reflect that in validation and normalization, not in your database storage.

Frequently Asked Questions

No. Regex can validate the string format, but it cannot prove the value was generated correctly or meets application-specific rules. Parser-based validation is stricter.

Use regex for quick format checks and parser APIs for strict validation. In most apps, the best flow is normalize input, run an optional regex check, then parse with a trusted API.

Use the canonical hyphenated pattern on this page when you want the standard 8-4-4-4-12 format without braces or a URN prefix.

They use the same runtime regex behavior. TypeScript helps you wrap validation in typed helpers, but it does not change how the regex engine works.

Only if your application truly depends on specific versions or RFC variants. Otherwise, a simpler canonical pattern is easier to maintain and less likely to reject valid input your system still accepts.

Try our GUID / UUID Validator to validate, decode & analyze your input.

By using this site, you agree to our Privacy Policy and Terms of Service. You are not permitted to use the GUIDs (also known as UUIDs) generated by this site or use any other content, services and information available if you do not agree to these terms.
Disclaimer: All information is provided for general educational and technical reference only. While we aim to keep the content accurate, current and aligned with published standards, no guarantees are made regarding completeness, correctness or suitability for any specific use case.
GUID specifications, best practices, security guidance, database behavior and ecosystem conventions (including cloud platforms and identifier formats) may change over time or differ by implementation. Examples, recommendations and comparisons are illustrative and may not apply universally.
This content should not be considered legal, security, compliance or architectural advice. Before making critical design, security or production decisions, always consult the latest official standards and vendor-specific documentation.
Always evaluate behavior in your own environment.
Standards Compliance: The GUIDs generated by this site conform to RFC 4122 and RFC 9562 specifications whenever possible, using cryptographically secure random number generation.