UUID Validator

How to use the uuid validator

1. Paste the UUID.
2. Read the version and variant.
3. Check what the version reveals.

About this tool

Validating the format is the easy half. The useful half is the version, because different versions leak different things and "valid" hides that entirely.

A version 4 UUID is 122 bits of randomness and reveals nothing. A version 1 UUID encodes a timestamp and the generating machine's network address — publishing one tells anyone who looks when it was created and, potentially, which machine created it. That has been a real source of information disclosure in production systems. Version 7, which is newer, deliberately begins with a millisecond timestamp so that identifiers sort chronologically; that makes them far better as database keys and means they reveal creation time by design.

The variant field is also reported. Almost everything you will meet is the RFC 4122 variant; the others are legacy formats from Microsoft and the Apollo Network Computing System.

Common wrappers are accepted — braces, the `urn:uuid:` prefix, and uppercase — since those are how UUIDs actually arrive from different systems. A string with the right 32 hex digits but hyphens in the wrong places is rejected with an explanation rather than a bare failure, because some parsers accept those and some do not.

Common uses

• Checking an identifier before using it as a key.
• Finding out whether a UUID in a public URL leaks a timestamp.
• Confirming which UUID version a system produces.

Frequently asked questions

Which UUID version should I use?

Version 4 when the identifier must reveal nothing. Version 7 when you want database keys that sort chronologically and are content to reveal creation time.

What does a version 1 UUID reveal?

A timestamp and the generating machine's network address. Exposing one publicly discloses both, which has caused real information leaks.

Is the nil UUID valid?

Yes. All zeros is a defined special value meaning 'no value', as is the all-ones max UUID.