UUIDs let independent systems mint 128-bit identifiers without asking a central counter for the next value. That property is useful for records created offline, across services, or before insertion into a database. It does not turn an identifier into a secret, prove that no collision exists anywhere, or validate the record attached to it.
This guide uses the UUID generator and validator to inspect fixed RFC examples and create a small batch. It distinguishes random version 4 from time-ordered version 7, explains NIL and MAX, and sets practical verification boundaries without inventing benchmark or uniqueness guarantees.
Choose an identifier format for the system
UUID version 4 fills its non-version and non-variant bits with random or pseudorandom data. It is widely supported and reveals no creation timestamp in its defined layout. UUID version 7 places a Unix epoch millisecond timestamp in the most significant 48 bits and uses the remaining available bits for random data and optional monotonic techniques. Its byte order is designed to follow creation time more naturally.
Choose based on interoperability, ordering needs, and the libraries supported by every participant. Do not claim that v7 makes every database faster: storage format, index type, workload, generator behavior, and database implementation all affect results. Do not choose v4 because it “looks more secure.” Both are public identifiers when exposed in a URL or payload.
Fixed examples to inspect
Use these values unchanged:
550e8400-e29b-41d4-a716-446655440000
017f22e2-79b0-7cc3-98c4-dc0c0c07398f
00000000-0000-0000-0000-000000000000
ffffffff-ffff-ffff-ffff-ffffffffffff
The validator identifies the first as a valid v4 UUID and the second as a valid v7 UUID. The third is the special NIL UUID and the fourth is the special MAX UUID. NIL and MAX are valid special forms but do not report an ordinary version. Change the final character of the v4 sample to z; validation must fail because the textual representation allows hexadecimal digits, not arbitrary letters.
Generated values are intentionally not fixed. Select v7 and generate three identifiers. Each must validate as v7, but this guide cannot predict their exact text. Repeat with v4 and verify version 4 rather than comparing against a snapshot.
Generate and validate a small batch
Open the localized tool, select v4, set the count to three, and generate. Confirm that exactly three lines appear. Copy the batch and validate each line independently. Repeat with v7. Preserve generation order when testing whether your storage system sorts v7 values usefully, and compare the binary or canonical text representation consistently.
Paste each fixed value into the independent validator. Record validity, detected version, and special status. Then test the invalid 550e8400-e29b-41d4-a716-44665544000z. Format validation should reject it; this says nothing about whether a valid value exists in your database.
For a larger batch, choose between 1 and 1,000 values. Download the text file and count non-empty lines. The limit prevents accidental browser-heavy output; it is not a recommendation to allocate identifiers in blocks of 1,000. Generate identifiers at the point your architecture requires, with the same trusted library in production.
Read the bits without overinterpreting them
RFC 9562 defines the canonical 8-4-4-4-12 hexadecimal grouping, the variant field, and a four-bit version field. In v4, the version nibble is 4; the RFC variant begins with binary 10. In v7, the version nibble is 7, and the first 48 bits hold Unix epoch milliseconds. The remaining 74 bits, excluding version and variant, provide random data or a specified combination that can improve monotonicity within one millisecond.
The generator delegates to a maintained UUID library and cryptographic randomness supplied by the environment. It does not use Math.random. If secure randomness is unavailable, generation fails rather than substituting a weaker source. Validation checks syntax, variant, version, and special values according to the library; it does not query a registry.
NIL contains all zero bits and MAX all one bits. They are useful sentinels in protocols that define them, but inventing local meanings can create ambiguity. Document whether they are forbidden, reserved, or meaningful in your schema.
Understand what validation cannot tell you
Invalid input often has the wrong number of hexadecimal characters, misplaced hyphens, a non-hex character, unsupported variant, or an unrecognized version. Copy the canonical text without braces or prefixes unless the receiving system explicitly accepts them. Trimming surrounding whitespace is different from changing the identifier itself.
A valid result does not prove existence, ownership, freshness, uniqueness in a database, or authorization. Check existence against the relevant datastore and enforce a unique constraint where collisions would be harmful. Handle insertion conflicts even when their probability is extremely low. Validation also cannot reveal whether a v4 was produced with secure randomness; it sees the final bit layout only.
If generation reports that secure crypto is unavailable, change to a supported browser or runtime. Do not fall back to handwritten random strings. If a count is below 1, above 1,000, or non-integral, correct the request rather than slicing an oversized result.
Design the surrounding identifier policy
Store UUIDs consistently as canonical text or 16-byte binary according to database and driver support. Mixed byte orders can make otherwise valid values compare differently. Treat textual UUIDs case-insensitively where the protocol allows it, but emit one canonical form for logs and APIs.
Never use a UUID as a password, API key, bearer token, or proof that someone may access a record. Version 7 exposes an approximate creation time in its leading field, and version 4’s opacity is not authentication. Use cryptographically generated secrets with adequate entropy and a separate authorization check.
For public URLs, consider whether predictable creation ordering or resource enumeration matters even when exact IDs cannot be guessed. Rate limits, access control, and response behavior still matter. Keep UUIDs out of logs only when the data classification requires it; replacing secrets with UUIDs does not make a log harmless.
Limits of this generator and validator
The tool supports generation of v4 and v7 batches from 1 to 1,000 and inspection of UUID text, including NIL and MAX. It does not generate every UUID version, provide a central uniqueness registry, check a database, reserve values, or guarantee global uniqueness. The RFC describes collision resistance and generation considerations, but an application must still enforce its own consistency rules.
Time ordering in v7 is not a complete event order across machines. Clocks can move, multiple values can share a millisecond, and implementations may use different monotonic methods. A UUID is also not a timestamp API: extract or display creation time only when your protocol explicitly relies on that defined field.
Final UUID checklist
Choose v4 or v7 based on an explicit compatibility and ordering requirement. Use a maintained generator with secure randomness. Store one representation consistently and enforce uniqueness where required. Keep authentication secrets and authorization separate from identifiers.
Validate the two fixed samples as v4 and v7, recognize NIL and MAX, and reject the sample ending in z. For generated batches, verify count and version instead of expected text. Test database insertion, conflict handling, serialization, and sorting with your actual driver before adopting a storage claim.
Keep the generator version and storage representation in the test record.
Sources: RFC 9562: Universally Unique IDentifiers, uuid package documentation, and Web Cryptography API specification.