UUID Validator
Validate RFC 4122 compliant UUIDs (Universally Unique Identifiers) instantly and determine their version and basic structure.
UUID Validator
What is UUID Validation?
UUID validation verifies that a string conforms to the RFC 4122 specification for Universally Unique Identifiers. A valid UUID must have the correct length (32 hexadecimal digits plus optional 4 hyphens), use only valid hexadecimal characters (0-9, a-f, A-F), follow the proper format (8-4-4-4-12 hyphen pattern), and have correct version and variant bits in their designated positions.
Validating UUIDs before processing them prevents errors in your application, database, or API. Invalid UUIDs can cause crashes, database constraint violations, or silent data corruption. Proper validation at input boundaries (API endpoints, file imports, user forms) ensures data quality and system reliability. This is especially important when accepting UUIDs from external sources, third-party integrations, or user input.
This validator checks both format (string structure) and RFC 4122 compliance (version and variant bits). It identifies common problems: incorrect length, non-hexadecimal characters, wrong hyphen placement, invalid version numbers, and non-RFC 4122 variants. The validator provides clear feedback about what's wrong with invalid UUIDs, making it easy to troubleshoot UUID generation or parsing issues.
Common Use Cases for UUID Validation
API Input Validation
Validate UUID parameters in REST API endpoints before processing requests. Check that user IDs, resource identifiers, session tokens, or correlation IDs are valid UUIDs. Return 400 Bad Request with clear error messages for invalid UUIDs instead of allowing them to propagate through your system causing crashes or security issues.
Database Data Quality
Validate UUIDs before inserting into databases, especially when importing data from CSV files, legacy systems, or external sources. Catch malformed UUIDs before they violate database constraints or corrupt data. Validation during ETL processes ensures only well-formed identifiers enter your data warehouse.
User Input Sanitization
Validate UUIDs entered by users in forms, configuration files, or command-line tools. Provide immediate feedback when users paste malformed identifiers. This improves user experience by catching errors early and prevents downstream issues from propagating through your application workflow.
Testing UUID Generation
Verify that your UUID generation functions produce RFC 4122 compliant identifiers. Use validation in unit tests to ensure generated UUIDs have correct version numbers, proper variant bits, and valid format. This catches configuration errors or library bugs before they reach production.
Integration Point Verification
Validate UUIDs at integration boundaries when receiving data from microservices, third-party APIs, or partner systems. Different systems may use different UUID formats or non-standard identifiers. Validation ensures you only process compatible identifiers and reject incompatible formats early.
Migration and Data Cleanup
Audit existing databases for invalid UUIDs before migrations or schema changes. Identify and fix malformed identifiers, non-RFC compliant UUIDs, or corrupted data. Validation helps ensure data quality when consolidating multiple systems or upgrading database platforms.
What This Validator Checks
Format and Structure
Verifies the UUID has exactly 32 hexadecimal digits, optionally separated by 4 hyphens in the pattern 8-4-4-4-12. Checks that all characters are valid hexadecimal (0-9, a-f, A-F). Accepts both uppercase and lowercase. Rejects strings that are too short, too long, have hyphens in wrong positions, or contain non-hex characters like 'g', 'z', or special symbols.
Version Number Validation
Checks the version bits (4 bits at position 13 in hyphenated format) to ensure they indicate a valid version: 1 (time-based), 3 (MD5 name-based), 4 (random), 5 (SHA-1 name-based), 7 (time- ordered), or 0 (NIL UUID). Rejects UUIDs with version numbers 2, 6, 8-15 as these are either reserved or not part of the standard specification.
RFC 4122 Variant Compliance
Validates the variant bits (2-3 bits at position 17) to ensure the UUID follows RFC 4122 specification. The variant should be "10" in binary (decimal 8-11 in the relevant hex digit position). Flags UUIDs with variants from older specifications (NCS, Microsoft reserved, future reserved) that use different bit layouts and may not be compatible with RFC 4122 tools.
NIL UUID Recognition
Recognizes the special NIL UUID (00000000-0000-0000-0000- 000000000000), a reserved value representing "no UUID" or an absent identifier. While technically valid in structure, the validator notes when you're checking the NIL UUID, as it should only be used as a placeholder value, never as an actual entity identifier.
Frequently Asked Questions
What makes a UUID invalid?
Common reasons for invalid UUIDs: wrong length (not 32 hex digits), non-hexadecimal characters, incorrect hyphen placement (should be 8-4-4-4-12), invalid version number (must be 1, 3, 4, 5, 7, or 0 for NIL), or wrong variant bits (should be RFC 4122 variant). Also invalid: missing hyphens when expected, extra characters, leading/ trailing whitespace, or completely random strings that happen to be 32 characters.
Can a UUID be valid but still unusable?
Yes. A UUID can be structurally valid (correct format, valid version/variant bits) but still problematic: it could be a duplicate, the NIL UUID used as a real identifier, a manually created non-random v4 UUID with predictable values, or a v1 UUID with an invalid timestamp. Format validation only checks structure, not uniqueness, randomness quality, or whether the UUID was generated properly.
Should I validate UUIDs in production code?
Yes, especially at API boundaries and input points. Validate UUIDs from user input, external APIs, file uploads, or any untrusted source. However, skip validation for UUIDs your own code generates— that's redundant if you trust your generation library. Balance performance and security: validate at entry points, trust internal data after validation, and use fast regex or built-in validation functions rather than complex parsing.
Are uppercase and lowercase UUIDs both valid?
Yes, RFC 4122 accepts both uppercase and lowercase hexadecimal digits. However, the canonical format uses lowercase. Most systems normalize UUIDs to lowercase for consistency. When validating, accept both cases but consider normalizing to lowercase in your storage and APIs to prevent duplicate entries from case differences (e.g., treating A1B2... and a1b2... as different values).
Do UUIDs always need hyphens?
No. UUIDs can be represented with or without hyphens. The canonical format includes hyphens (36 characters total), but the compact format without hyphens (32 hex digits) is also valid and commonly used for space efficiency. This validator accepts both formats. When accepting UUID input, support both formats but normalize to your preferred representation for storage.
What's the difference between format and RFC compliance?
Format validation checks string structure: length, hexadecimal characters, hyphen placement. RFC 4122 compliance additionally validates version and variant bits are set correctly according to the specification. A UUID can have valid format but fail RFC compliance if version/variant bits are wrong. Always validate both for true UUID compliance—format alone isn't enough.
How do I fix invalid UUIDs in my database?
First, query for invalid UUIDs using validation logic in your database. For malformed UUIDs, regenerate them if they're not referenced elsewhere, or update references if they are. For UUIDs with wrong format (e.g., missing hyphens), normalize them. For corrupted data, check backups or source systems. Prevention is key: add validation constraints, use native UUID types, and validate input at application boundaries.
Can validation guarantee UUID uniqueness?
No. Validation only checks format and structure, not uniqueness. Multiple UUIDs can all be valid but duplicate. Uniqueness depends on proper generation (using sufficient randomness for v4, unique timestamps/nodes for v1, etc.) and your data model. Enforce uniqueness through database unique constraints, not validation alone. Validation prevents malformed UUIDs; constraints prevent duplicates.
Should I use regex or a library for UUID validation?
For simple format validation, regex is fast and sufficient. For complete RFC 4122 compliance checking (version/variant validation), use a library or more detailed parsing. Most languages have UUID validation in standard libraries (Python uuid.UUID(), JavaScript libraries, etc.). Regex is fine for basic checks, but libraries provide better error messages and handle edge cases correctly.
Is this validator safe for production UUID checking?
Yes for ad-hoc testing and debugging, but implement validation in your application code for production systems. This browser tool is perfect for manual verification, troubleshooting, or educational purposes. For production, use robust validation libraries in your backend that handle edge cases, provide detailed error messages, and integrate with your error handling framework.
Best Practices for UUID Validation
Validate at API boundaries: Always validate UUID input at REST API endpoints, GraphQL resolvers, RPC handlers, and other entry points to your system. Return 400 Bad Request with descriptive error messages for invalid UUIDs. Never let invalid UUIDs propagate into your business logic or database layers where they can cause crashes or data corruption.
Use appropriate validation depth: For public APIs, validate format, version, and variant. For internal services where you control generation, lighter validation may suffice. Balance security/reliability with performance. Don't re-validate UUIDs that have already passed validation at entry points unless there's a security boundary.
Normalize after validation: After validating, normalize UUIDs to a consistent format (lowercase, hyphenated) to prevent duplicate entries from case or formatting differences. Store normalized UUIDs consistently across your system. Document your normalization strategy in API documentation.
Provide helpful error messages: When validation fails, return specific error messages: "UUID too short", "Invalid character 'Z' at position 15", "Invalid version 6". This helps developers debug integration issues quickly. Generic "Invalid UUID" errors waste time.
Consider version requirements: Some applications may require specific UUID versions (e.g., only accept v4 random UUIDs). Validate not just RFC compliance but also that the version matches your requirements. Document version requirements in API specifications.
Test edge cases: In your validation tests, include edge cases: NIL UUID, uppercase vs lowercase, with and without hyphens, almost-valid UUIDs (31 or 33 characters), non-hex characters that look hexadecimal (like 'g'), and UUIDs with valid format but invalid version/variant bits.
Related UUID Tools
Explore our complete suite of UUID tools for generation, validation, decoding, and format conversion: