formatter.input (UUID)
validator.uuid.mode
formatter.output
validator.jwt.pasteAndValidate
Supports v1–v8, nil, max, GUID, batch mode
validator.jwt.pasteAndValidate
Supports v1–v8, nil, max, GUID, batch mode
A UUID is 36 characters. Hyphens in four specific positions.
It looks simple. And it is — until a UUID from a legacy system doesn't quite match the format your modern service expects. Until a GUID from a Windows system needs to work with a UUID-aware database schema. Until someone hand-edits a UUID in a config file and introduces a typo that's nearly invisible to the human eye.
Paste any UUID string above. Know instantly whether it's valid, which version it is, which variant it uses, and exactly what's wrong if it isn't.
UUID (Universally Unique Identifier) is a 128-bit value represented as a 32-character hex string split into five groups: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. Despite the "random" look, it carries structured info: version, variant, and sometimes timestamp/MAC address.
For v4 UUIDs, uniqueness is probabilistic (1 in 2^122 chance of collision). For v1/v7, it depends on time and node ID.
Time-sortable but leaks MAC address (privacy risk). Used natively by Cassandra.
Deterministic hashing. Same input = same UUID. MD5 is broken; prefer v5.
122 bits of randomness. Most common version. Identifying but not sortable.
Deterministic hashing like v3, but uses SHA-1. Preferred for name-based UUIDs.
Unix timestamp prefix + random suffix. Time-sortable AND random. Best for DB keys.
Almost. GUID is Microsoft's implementation of UUID. They follow the same RFC 4122 standard but differ in presentation and legacy byte ordering.
550e8400-e29b-41d4-a716-446655440000Lowercase, no braces. The standard for APIs and Linux/Unix systems.
{550E8400-E29B-41D4-A716-446655440000}Uppercase, often wrapped in braces. Standard for Windows/.NET.
Using UUID v4 as a primary key can kill database performance.
The Problem: v4 UUIDs are random. Inserting them into a B-tree index (standard for Primary Keys) causes random page access, fragmentation, and cache thrashing.
The Solution: Use UUID v7 (timestamp-first) or ULID. They are sortable, meaning new records append to the end of the index, keeping insertions fast and fragmentation low.
For high-performance DB keys, use UUID v7 (or v6/ULID). Use v4 only if write throughput is low.
Wrong length (must be 36 chars), non-hex characters (g-z), or missing hyphens at specific positions (8-4-4-4-12).
v1 = Timestamp + MAC Address (sortable but not private). v4 = Pure Randomness (private but not sortable).
00000000-0000-0000-0000-000000000000. It's a special 'null' value defined in the spec.
Practically yes. v4 collision probability is 1 in 2^122. You're more likely to be hit by a meteorite than generate a duplicate.
Yes, v4 provides enough entropy (122 bits). But consider using a signed token (JWT) or opaque token with metadata instead.
It combines uniqueness (random tail) with sortability (timestamp head). Perfect for database primary keys.
Functionally yes. GUID is Microsoft's name for UUID. They follow same structure but GUIDs are usually uppercase with braces.
No. UUIDs are case-insensitive hex. However, standard format is lowercase.
Bits that identify the standard. Most modern UUIDs are variant 1 (RFC 4122). Microsoft GUIDs use a legacy variant.
Paste any UUID or GUID above — any version, any case — and know in one second whether it's valid.