Most generated data sits in the comfortable middle of every format — a medium-length name, a mid-month date, an ordinary identifier. That is precisely the data that never finds your bugs, because the bugs live at the boundaries, in the rejection paths, and in the hostile corners of Unicode.
To test those you need three things average data cannot give you: values pushed to the rare-but-valid corners, values that are deliberately wrong, and values that are perfectly correct yet encoded in the nastiest way a real system ever meets. Real Fake Data makes each a single flag. Faker offers none of the three as a built-in mode.
edge=true — valid, but from the corners
Set edge=true on any generator and every record is drawn from the awkward-but-legal edges of its format: the longest RFC-valid email local part, the maximum-length name, leap-year dates, the serial ranges most likely to trip a hand-rolled parser. Nothing is invalid — every value still passes the format’s own validation — it is just chosen from the corners instead of the middle. That is what surfaces the column that is one character too short, the date parser that assumed two digits, the regex that forgot apostrophes are legal.
invalid=true — wrong on purpose
Set invalid=true and you get the opposite: values that are deliberately broken — a PESEL with a wrong check digit, an IBAN that fails mod-97, a malformed postcode. This is how you prove your rejection paths actually reject. A negative test is only meaningful if the bad input is genuinely bad in the specific way your validator is supposed to catch, and hand-rolling that per format is tedious and error-prone. Here it is a flag.
extreme=true — correct, but hostile
Set extreme=true and the value stays entirely correct — passing checksums, real content — but is wrapped in the most disturbing encoding production systems actually encounter. Each record gets one hostile class: untrimmed whitespace (non-breaking spaces, a trailing newline); invisible and zero-width characters behind a leading byte-order mark; homoglyphs (Cyrillic, Greek, or fullwidth lookalikes that read as Latin); or a right-to-left override with stacked combining marks. Ask for a batch and it rotates across all four.
It answers a question edge and invalid never reach: does your pipeline trim, normalise to NFKC, and compare safely — or does a zero-width space break a login, a homoglyph slip past a moderation filter, a right-to-left override scramble a rendered invoice? The mangling is careful and recoverable: identifiers keep their digits ASCII so they still parse and checksum after normalisation, and only the human-facing string is touched. (The lorem and custom-regex endpoints don’t take it, since it would break their length and pattern contracts.)
What Faker offers here
Faker has no equivalent built-in mode for any of the three. It draws from its data lists without a boundary-biasing switch, has no “make this fail validation” toggle, and no hostile-encoding wrapper. You can construct edge, broken, or Unicode-mangled values by hand on top of Faker — but that is exactly the work these flags remove, and getting each one right by hand (a checksum that is wrong in the way your validator catches; a homoglyph set that still round-trips through NFKC) is its own small project.
Try it
Flip any of the three flags on any generator:
curl "https://api.real-fake-data.com/v1/person-name?edge=true"
curl "https://api.real-fake-data.com/v1/pl-person?invalid=true"
curl "https://api.real-fake-data.com/v1/pl/person-name?extreme=true"Edge, invalid and extreme modes are available on the Pro and Self-hosted plans.