Hashes, IDs, and randomness
Generate test IDs and random strings
Tools to use
IDs 1, 2 and 3 may be enough to test a list UI, but are unsuitable as secret invitation-link tokens. The method depends on whether you need distinct identifiers, unpredictability or reproducible fixtures. Randomness is not one interchangeable feature; separate these three goals.
Generate three UUIDs and read their structure
Generate three v4 UUIDs. Values change on each run, so do not expect a fixed example output. The usual hexadecimal grouping is 8-4-4-4-12, totaling 36 characters with hyphens. Version bits, including the leading 4 in the third group, are fixed; not all 128 bits are random.
550e8400-e29b-41d4-a716-446655440000Inspect a generated value to check its format and version. A valid format does not prove that it identifies an existing user or record; this tool queries no database. Format validation and authorization tests are separate. A long identifier does not replace access control.
v7 carries time information as well as randomness
v7 includes Unix milliseconds near the beginning, which the inspection tool can display. Its layout supports time-oriented ordering, but does not prove an operation completed at that time. Device clocks, generation behavior and reusing IDs affect interpretation. Keep authoritative event times separately rather than deriving an audit record solely from an ID.
Do not assume universal ordering across same-millisecond generation or different devices. Choose v4 or v7 according to identifier and storage requirements. Exposing v7 also exposes its time-bearing structure. A newer version is not automatically preferable for every secret-token use.
For random tokens, count source bytes before characters
Generate 32 bytes as hex: the output has 64 characters. Base64url without padding represents 32 bytes in 43 characters. The shorter representation does not contain fewer random bits. Separate runs generate new bytes, so do not expect their strings to encode the same value; compare the length relationship instead.
The tool uses cryptographic randomness and does not fall back to Math.random. It does not handle distribution, storage or revocation. Expiration, single use and permissions for invitation or reset links are application responsibilities. Generating a long random value does not establish the safety of the whole link workflow.
Reproducible fixtures have a different goal
Random changes can obscure a reproducible UI or data-processing bug. Use dummy-data generation with the same schema, row count and seed when you need repeatable fixtures. That goal is opposite to unpredictable secrets. Values reproducible from a seed must not become passwords or authentication tokens.
Tests of a random generator should check count, format, alphabet, version and requested byte size, rather than one fixed string. A small collision-free sample does not prove collisions are impossible. Storage systems still need uniqueness rules and a policy for handling collisions.
Human-entered values have usability constraints too
Human-entered passwords may benefit from excluding lookalikes such as 0/O and 1/l. Use the password generator's alphabet and exclusion settings, checking destination length and symbol rules. Requiring several character groups needs enough length to include them. Specify requirements during generation instead of appending a predictable pattern afterward.
Name the purpose: UUID for identifying records, a suitably sized random token for an unpredictable secret, seeded fictional data for reproducing a bug. None requires copying real personal data into fixtures. Before sharing generated output, distinguish ordinary identifiers from secrets and handle clipboards and screen sharing accordingly.
Distinct IDs do not create distinct test situations
A hundred UUIDs provide distinct identifiers, not a hundred meaningful test states. If names, statuses and lengths are identical, many UI cases remain untested. Design empty and long names, equal timestamps and duplicate display names with distinct IDs separately. For a reproducible bug, deliberately capture generated IDs in a fixture rather than expecting the generator to reproduce them.
A valid UUID format does not prove the record exists; a fictional valid ID can test a not-found state. Replacing real-shaped IDs with short counters may hide wrapping or length limits. Choose format, existence, length and reproducibility according to the test. Do not confuse identifier requirements with secret-token or password requirements.
Keep production user IDs and real tokens out of distributed fixtures. Fictional values usually suffice for shape and layout tests. Label copied values by purpose so they are not mistaken for real credentials later. Since the tool does not autosave inputs or results, deliberately retain only what reproduction needs. Random generation, repeatable fixtures and operational secrets are different uses.