How Accurate Is US Address Parsing on Messy Input?

Real addresses get typed badly. People swap letters, forget the ZIP, put things in the wrong order, and spell streets the way they sound. So the useful question about an address parser is a simple one: what does it do with the mess?

We took 200,000 real US delivery addresses and broke them on purpose: typos, missing city, state, or ZIP, scrambled order, sound-alike street spellings. Then we asked our parser to work out the original address from each broken version. Three things stood out.

One thing before the numbers. We only scored addresses we could first confirm are real. If an address cannot be verified against postal reference data, no parser can recover a broken version of it, so counting those would only muddy the result. The rest of this post walks through each number.

What we tested

We started from a large set of real US delivery addresses and generated controlled corruptions of each one, spanning 31 corruption types ordered from mild to severe:

• Single and multiple typos, letter transpositions, and phonetic street spellings
• Dropped city, dropped state, dropped ZIP, and dropped street directionals
• Reordered fields, including fully reversed order and state-before-city forms
• Separator and casing noise: no commas, semicolons, extra spaces, all lowercase, all uppercase

The test had two steps. Step one: check each address in its clean form and keep only the ones that resolve to a real postal address. That was 72.8% of our sample. Step two: take 29,966 corrupted variants of those verified addresses, sampled at random from more than a million we generated, and send each one to the live parser in its maximum-recovery mode. Random selection matters here. It means the mix looks like the noise a real integration sees, and nothing was hand-picked to look good.

To keep the numbers honest, the parser had never seen any of these addresses as reference data. A parser tested on data it was built from always looks better than it really is. And because every address in the test is verifiably real, every miss in this report is a genuine miss. There is no fine print behind the number.

Recovery: the right address from a corrupted one

Recovery means one thing: given a corrupted input, the parser returned the correct address, standardized. One reading note before the table. The corruption classes are not equally common in real life. Casing problems, separator noise, a typo, a dropped field: that is the overwhelming majority of what production traffic looks like, and it recovers at 96% to 99.9%. The compound class, several severe corruptions deliberately stacked on one input, is a stress test we built to find the breaking point. It drags the average down, and we report it anyway. Here is how it did:

None of this was measured on tidy inputs. Below are 20 real benchmark inputs the parser recovered correctly, five per severity class, color coded from compound damage down to formatting-only corruption. The middle column is exactly what went in. The last column is the match signal the parser returned: Exact when the address was never in doubt, and Near, Approximate, or Speculative with a confidence score when it had to correct or infer a field.

Notice two things. The parser also cleaned up the casing and filled in the ZIP+4 wherever it could. And look at the last column: formatting-only corruption came back Exact, while every typo, dropped field, and reorder came back marked as a correction. It never pretended a repaired address was an exact match.

When it is unsure, it tells you

A miss will rarely hurt you. You get no answer, you see it, you handle it. The dangerous case is a silent substitution: the parser returns a different address than the one you meant and stamps it as an exact, high-confidence match. No warning. That is how a package ends up at the wrong house while everyone believes the data was clean.

In this test, that happened on at most 37 inputs out of 26,943, about 1 in 700. We say "at most" because we scored against reference data that has flaws of its own, so some of those 37 answers may actually be fine. Not one of them had the wrong state. Everything else that was wrong or uncertain came with a warning. When the parser changes something, it lowers the match tier and the confidence score:

• matchTier drops from Exact to Near, Approximate, or Speculative
• confidence drops below 1
• matchCode flags which components were corrected or left unconfirmed

Here is one of the heavier inputs from the benchmark: a misspelled street, a misspelled city, a misspelled state, and no ZIP. This is the response it produced.

// input:  "2 emreald ln doevr new hmapshire"
{
  "fullAddress": "2 Emerald Ln, Dover, NH 03820",
  "matchTier": "Approximate",
  "confidence": 0.7,
  "matchCode": {
    "houseNumber": "Matched",
    "street": "Corrected",
    "city": "Inferred",
    "state": "Matched",
    "zipCode": "Inferred"
  }
}

The parser corrected the street, inferred the city and ZIP, and did not pretend to be certain. It returned Approximate at confidence 0.7 with a per-field breakdown of exactly what it changed.

This lets you set a simple rule in your code. Accept exact, high-confidence results automatically. Send anything marked corrected or approximate to a review step. In this run, 918 answers were wrong and said so themselves: their tier and confidence told you up front to double-check them.

Refusing addresses that do not exist

A parser that always returns something is easy to build and dangerous to use. So we also fed it poisoned input: made-up house numbers, the wrong state for a ZIP, the wrong ZIP for a city, and flipped street directions. The right response there is to refuse, to flag the fix, or to restore the true address. The parser did one of those 99.5% of the time. For made-up house numbers specifically, it returned nothing 99.9% of the time instead of inventing a match.

It shows the same restraint on ordinary broken input. When too much of an address is destroyed, it returns nothing rather than guessing. That happened on 7.9% of the test, and the next section breaks down where.

Where recovery falls short

So where does the missing 11.5% go? Split it up: 7.9% refused to answer, 3.4% were wrong but flagged themselves, and at most 0.14% slipped through silently. Every address in the test is real, so the refusals are genuine misses. They pile up exactly where you would guess:

• Several typos and no ZIP. When the street and the city are both misspelled and there is no ZIP, there is not much left to work with. On those inputs alone, refusals run 31% to 38%. Could the parser guess? Sure. Guessing is how wrong-address databases get built, so it refuses instead. This is a deliberate choice, and it is the largest remaining group.
• Severely reordered input. Fully reversed and ZIP-first orderings still fail more than average when the reordering also strips the fields that anchor a search. This class got much smaller in recent releases and keeps shrinking.

We publish this because knowing where the parser fails is as useful as knowing where it works. It tells you exactly where to add a check in your own flow: if your form asks for a ZIP, you close most of the remaining gap.

What this means for your integration

• Trust the exact, high-confidence results. They are almost never silently wrong, so you can accept them without a human in the loop.
• Use the match tier and confidence as a routing signal. Send corrected or approximate answers to review or to a user confirmation step.
• Expect no answer on genuinely bad input. A refusal is information. Treat it as "ask the user to check," not as a bug.
• Provide a ZIP when you can. It is the single most valuable anchor when the rest of the input is noisy.

You can run the same kinds of inputs against the API yourself. The free tier includes 100 lookups every month, no card required.