Invalid Data Generator
Create invalid samples for emails, JSON, CSV, XML, dates, and phone numbers. These are malformed on purpose for testing validation and error handling. Content: intentionally invalid, for validation tests only.
Also known as: malformed data · invalid test data
seeded
Presets
Output
About this tool, tips & examples
What it does
The Invalid Data Generator produces deliberately malformed samples — broken emails, unparsable JSON, corrupt CSV, invalid XML, impossible dates, and wrong phone numbers — for negative testing. Each value is wrong in a realistic way: missing @ signs, unclosed brackets, February 30th, digit-count errors. Generate up to 1,000 per run, seeded so a failing case stays pinned.
Common use cases
- Validation testing — confirm every malformed input is rejected with a useful error, not a crash or a silent accept.
- Parser hardening — feed JSON/CSV/XML parsers input that’s almost valid, where the interesting bugs live.
- Error-message QA — check that users see “invalid email” rather than a stack trace.
- Import pipelines — verify that one bad row doesn’t kill a whole batch.
Settings
- Data Type — emails, JSON, CSV, XML, dates, or phone numbers (presets for emails, JSON, and dates).
- How many — 1 to 1,000 invalid samples per run.
- Seed — the same seed and settings reproduce the identical samples — cite the seed in bug reports.
Privacy note
Samples are generated locally in your browser and never uploaded. Everything is intentionally invalid synthetic content for testing — malformed by design, harmless by construction.
FAQ
Why “realistically” invalid instead of random garbage?
Random bytes get rejected by the first check. Almost-valid data — a date
like 2024-02-30, JSON with one trailing comma — penetrates deeper into
your logic, where the expensive bugs hide.
What should my code do with these? Reject each one gracefully: clear error, correct HTTP status, no partial state. If any sample gets accepted, that’s a finding.
Where are the valid-but-weird cases? That’s the neighbor tool: Edge Case Strings generates technically-valid hostile input (Unicode, huge lengths), and Fuzz Values covers boundary numbers and structures. Use all three for full negative coverage.