A UUID is a 128-bit identifier formatted as 32 hex digits in five groups, and its version and variant bits are baked directly into the value. v4 fills almost the whole thing with random bytes from the browser's crypto API, v1 embeds a timestamp plus a random node ID, and v3/v5 hash a namespace UUID together with a name — MD5 for v3, SHA-1 for v5 — so the same namespace and name always produce the identical UUID. The parser below reads those version/variant bits back out of any UUID you paste in, and for v1 it also decodes the embedded timestamp.
v1 encodes the current timestamp (100-nanosecond intervals since 1582) plus a node identifier directly into the UUID, which means UUIDs generated later sort roughly chronologically and the creation time can be extracted later — this tool's parser does exactly that. v4 is just 122 bits of randomness with no embedded meaning, which is why it's the default for most applications that don't need sortability.
v3 and v5 are deterministic: hashing the same namespace UUID and name always produces the same output UUID, which is useful when you need to generate a stable ID for something like a URL or DNS name without storing a lookup table. v5 (SHA-1) is generally preferred over v3 (MD5) today since MD5 is a weaker hash, but both exist mainly for compatibility with RFC 4122's original namespaces.
Not mathematically guaranteed, but the collision odds are negligible: with 122 random bits, you'd need to generate roughly a billion UUIDs per second for about 85 years before a 50% chance of any collision. For virtually every practical use — database keys, request IDs, file names — that's treated as effectively unique.