Format Validation vs. Delivery Point Validation
Format validation and Delivery Point Validation are two different checks, and a generated Fake Addresses record can pass one while failing the other on purpose. Format validation asks a narrower question: does this string parse into a street number, street name, suffix, city, state, and ZIP code in the right order, using recognized abbreviations? USPS Publication 28 calls the result of that check a "standardized" address, one using official abbreviations, and a "complete" address, one with everything needed to match the ZIP+4 and City State files (USPS Publication 28).
Delivery Point Validation asks a completely different, stricter question: is this specific street number an assigned, deliverable point on an actual mail route, right now? A record can be perfectly formatted — every abbreviation correct, every field in order — and still fail this check, because format correctness says nothing about whether a mail carrier has ever been assigned to walk up to that number.
Most competing address generators only clear the first bar, and not reliably. Fields composed independently — a real-looking street name paired with an arbitrary number, a city guessed from a ZIP code rather than looked up — routinely fail even basic format parsing, because the city, state, and ZIP code disagree with each other. Fake Addresses is built to always clear format validation and to always fail delivery validation, which is a narrower target than either competitor failure mode.
Synthetic Test Data Generation That Deliberately Fails Delivery Validation
Fake Addresses deliberately fails Delivery Point Validation by choosing street numbers from ranges the Postal Service has never assigned to a delivery point on that specific street segment, rather than by picking numbers at random and hoping none of them collide with a real address. The street itself is real, pulled from the [the national statistical agency road network]() for that ZIP Code Tabulation Area; the number on it is not.
This is the geographic coherence guarantee described in full on Fake Addresses' methodology page: every record is built from one point — a spot on a real street, inside the correct ZIP Code Tabulation Area — and the city, county, state, and area code are all derived from that same point, not composed independently and hoped into agreement. A street number with no registered delivery point is the last piece placed on top of that coherent point.
The result is a record that looks exactly like a real address because most of it is real — the street exists, the ZIP code is correct, the city name matches what the Postal Service actually calls that ZIP code — while the one field that would make it deliverable is deliberately absent. That is a narrower, harder target than generating an address that merely sounds plausible, and it is the reason Fake Addresses treats non-deliverability as something to prove, not just assert.
The Measured Non-Deliverability Claim
Not as an absolute, unprovable guarantee — as a measured, re-checked figure, once the nightly Delivery Point Validation sample has run. That sample has not run yet, so Fake Addresses does not publish a non-deliverability count today; when it does, the number will be read directly from the log, never typed by hand, and the build stops shipping if a sample is ever not clean.
That figure is read directly from the sample log described on the methodology page, never typed in by hand. It is also allowed to say something other than zero: if any record is ever confirmed deliverable, the public counter pauses, the street-number range involved is excluded going forward, and the build does not ship again until the sample comes back clean.
A QA engineer evaluating this claim does not need to take Fake Addresses' word for it. The same sample-log format is designed to be rerun against any dataset version, so the measured figure updates as ZCTA and street data refresh, rather than sitting frozen as an old snapshot nobody has checked recently.
This is a deliberately narrower claim than "these addresses are fake" or "these addresses cannot be real." Nobody can prove a negative about every address on earth. What can be measured, and re-measured every night, is whether a specific, disclosed sample size of this specific dataset version comes back confirmed by the authority that actually knows which points are deliverable — the Postal Service itself.
What This Means for CI and Staging Environments
A test suite that generates and validates Fake Addresses records in CI needs both properties at once, which is why the format/delivery split matters practically, not just legally. A test address that fails format validation breaks the form-level test before the interesting assertion runs — an insurance-policy field, a shipping-rate calculator, a duplicate-address check — none of which are what the test is supposed to be exercising. A test address that accidentally passes Delivery Point Validation is worse: it means the fixture has drifted into describing a real [ZIP Code Tabulation Area]()'s real mailbox (U.S. the national statistical agency maintains the ZCTA boundaries this is checked against), which is a data-hygiene incident, not a passing test.
Fake Addresses ships a ?seed= parameter specifically so this behavior is reproducible: the same seed against the same dataset version returns the same record, forever. A CI fixture that asserts "this address passes format validation and fails delivery validation" keeps passing across every future run, not just the run where it was written, because the underlying record it checks against never silently changes. Pinning both the seed and the dataset version, documented on the API page, is what makes that guarantee hold even after a nightly data refresh changes other records elsewhere in the dataset.
Frequently asked questions
Will these addresses pass address validation?
They pass format and parser validation — the check that confirms a street number, street name, suffix, city, state, and ZIP code are structured correctly — and they deliberately fail Delivery Point Validation, the stricter check that confirms a real carrier delivers to that exact number. Both halves are intentional.
Will a fake address pass AVS (address verification system)?
An Address Verification System compares a billing address against the address a card issuer has on file for that card; it is not a delivery check. A syntactically well-formed test address may pass an AVS field-format check, but it will not match any card issuer's real billing record, because it does not belong to a real account.
Can I confirm a Fake Addresses record is non-deliverable myself?
Yes — run it through any Delivery Point Validation service, including the free USPS address-validation API, the same way the nightly sample does. The public non-deliverability figure on the methodology page is produced exactly that way, so the check is reproducible rather than a claim to take on trust.
Why do most competing address generators fail basic format validation?
Most competitors assemble street, city, state, and ZIP code independently, without checking that the city and ZIP code actually agree — which is the majority of what causes a parser to reject the record. Fake Addresses derives every field from one point inside one ZIP Code Tabulation Area, so the fields cannot disagree with each other.
Sources
- United States Postal Service — Postal Explorer — USPS Publication 28 defines a "standardized address" as one using official USPS abbreviations, and a "complete address" as one containing everything needed to match the ZIP+4 and City State files.
- U.S. the national statistical agency — A ZCTA (ZIP Code Tabulation Area) is a the national statistical agency geographic approximation of a ZIP Code built from Census tabulation blocks; not every valid ZIP Code has a 2020 ZCTA.