UUID Generator and Validator
Generate up to 100 UUID v4 values with the browser CSPRNG, and check existing UUIDs for validity, version and v1 timestamp.
Test fixtures, identifiers for orders or uploaded files, and the recurring question of why an ID in the logs carries a timestamp - all of it turns into UUID work. Typing them by hand is not an option, and a string copied from somewhere else does not announce which version it is or whether its hyphen placement is legal.
Generation uses crypto.getRandomValues rather than Math.random, produces up to 100 values at a time, and can render them uppercase or without hyphens. The validator checks length, hyphen placement, hex characters and the version nibble, names the version it finds - v1, v3, v4, v5, v6, v7 or v8 - and recovers the generation timestamp from a v1 UUID. All of it happens locally.
What the versions are for
v4 is 122 random bits and the default choice for a new identifier. v3 and v5 hash a namespace plus a name with MD5 or SHA-1, so the same input always yields the same UUID - useful for stable identifiers derived from a URL or a domain name, and wrong for anything that has to be unpredictable. v1 packs a 60-bit timestamp, a clock sequence and a node value that is often the machine's MAC address: identifiers trend upward over time, which is friendly to database indexes, but they also broadcast when and where they were created. The newer generations fill known gaps: v6 reorders the v1 timestamp so it sorts correctly as text, v7 puts a Unix millisecond timestamp first for sortable, index-friendly IDs, and v8 leaves the layout to the application. The validator here recognizes all of them.
Why a v1 UUID reveals its creation time
The v1 timestamp counts 100-nanosecond intervals since 1582-10-15, the date of the Gregorian calendar reform, with 60 bits stored in three separate pieces in an order that does not match how you would read them. To recover the time, subtract the fixed offset to the Unix epoch, then divide by 10^7 to get seconds. Anyone can do this with the UUID alone and no key - which is why publishing v1 identifiers amounts to publishing when each record was created and, through the node field, often on which machine. For anything user-visible, prefer v4 or v5.
Randomness source and batch generation
This page draws from crypto.getRandomValues, a cryptographically secure generator; Math.random is seeded predictably and its output can be reconstructed from a few observed values, which is not what you want behind an identifier. Batch generation - up to 100 at a time, with uppercase and hyphen options to match a target system's format - covers fixtures, load tests and database seeds. One property to keep straight: a UUID is designed to be unique, not to be unguessable. If a value has to grant access, such as an invitation code or a password reset token, treat it as a secret with a signature, a rate limit and a server-side check rather than relying on the identifier alone.
Frequently asked questions
- Can UUID v4 collide?
- In theory, yes; in practice the probability is negligible. v4 carries 122 random bits, roughly 5.3 x 10^36 possible values, so even generating a billion of them leaves the collision chance vanishingly small. Duplicates in real systems come from a missing unique index or an ID generated twice, not from the randomness.
- What is the difference between a UUID and a GUID?
- Nothing structural. GUID is the Microsoft name for the same thing; UUID is the term used by RFC 4122 and its successor RFC 9562. Both are 32 hexadecimal characters in the 8-4-4-4-12 layout, and a parser written for one handles the other.
- Why do v3 and v5 produce the same value every time?
- They are deterministic by design: the UUID is the hash of a namespace UUID and a name string, MD5 for v3 and SHA-1 for v5, truncated and tagged with the version. Identical input always gives an identical result, which is exactly what makes them suitable for stable identifiers - and exactly why they must not be used for tokens.
- Is a UUID without hyphens still valid?
- The 32 hex characters still represent the same 128 bits and are widely accepted by databases and log formats, but the canonical form defined by the RFC is 8-4-4-4-12. Keep the hyphens when exchanging data with another system, since strict parsers reject the undivided string.