ZIP Code Lookup & Address Standardization: A Developer's Guide to USPS-Compliant Data

Standardisation rewrites a typed address into the canonical form the Postal Service expects. Verification is a different operation that asks whether that address exists and receives mail. Conflating the two is why checkout forms reject addresses that are perfectly real.

The two operations, kept apart

Standardisation is a transformation. Given a string, apply the Publication 28 rules: uppercase, strip punctuation, abbreviate the suffix and the directional, move the unit onto the delivery line, put the city, state and ZIP on the last line. It needs no external data beyond the abbreviation tables, it is deterministic, and you can do it locally in a few hundred lines.

Verification is a lookup. Given a standardised address, does it match a delivery point in the USPS address database — and if so, what is its ZIP+4, its delivery point code, is it residential or commercial, is it currently receiving mail. This cannot be computed. It requires the database.

Everything that goes wrong in this area comes from code that does the first and claims the second.

Three worked examples

1. A suite on its own line, and a spelled-out everything

Input:
  Acme Logistics, Inc.
  Suite 400
  1244 North Maple Avenue
  Los Angeles, California 90012

Standardised:
  ACME LOGISTICS INC
  1244 N MAPLE AVE STE 400
  LOS ANGELES CA 90012

The suite moves *onto* the delivery address line rather than staying above it — the rule people most often get backwards. North becomes the pre-directional N, Avenue becomes AVE, California becomes CA, and the punctuation goes, including the period in Inc. and the comma after the city. Note what did not happen: no ZIP+4 was added, because that would require a database match.

2. A hash, a rural route, and a lowercase mess

Input:
  jane doe
  rr 2 box 152a
  #3
  bent fork, ar 72015

Standardised:
  JANE DOE
  RR 2 BOX 152A # 3
  BENT FORK AR 72015

Rural route addresses have no street name at all and are entirely valid. RR 2 BOX 152A is the delivery address. The #3 is a unit of unknown type, so it standardises to # 3 — hash, space, number — and is appended to the delivery line. A form that strips # as a special character, or that requires a numeric street number, rejects this address. Roughly one in a hundred US addresses is a rural route or highway contract route.

3. A street genuinely named for a direction, plus a PO Box

Input:
  Compass Trading Co
  1900 North Street
  PO Box 1840
  Nacogdoches, TX 75961

Standardised:
  COMPASS TRADING CO
  1900 NORTH ST
  PO BOX 1840
  NACOGDOCHES TX 75961

Two traps. North Street is a street *named* North — it is not a pre-directional — so it stays spelled out. Abbreviating it to 1900 N ST would name a different street, and you cannot tell which case you are in from the string alone; it needs the address database for that city. Second, with both a street address and a box present, the Postal Service delivers to whichever sits on the delivery address line — here the box, because it is last before the city line. Swap those two lines and the mail goes to the street.

A detail that bites: the PO Box usually carries a different ZIP+4 from the street address at the same site, because the box section is its own delivery unit.

What a lookup can and cannot answer

A ZIP lookup resolves a five-digit code to the postal city, state, county and timezone recorded for it. Useful, and narrower than it sounds:

• The city it returns is the postal city — the name of the delivery office, which often is not the municipality a resident would give. Mail addressed with the municipality still arrives; a form that rejects it is wrong.
• A ZIP can span states and counties, so a single answer is sometimes a simplification. 42223 straddles Kentucky and Tennessee.
• Matching ZIP to city is a weak check. The common bug is not an invalid ZIP but a valid ZIP paired with the wrong city — and because one city holds many ZIPs and one ZIP can cover several places, a strict match rejects real addresses. Treat a mismatch as a prompt, not a rejection.

The first three digits — the prefix — are the more reliable unit: each prefix is assigned to one state, so a prefix can contradict a state claim with more confidence than a full ZIP can confirm a city.

CASS certification, and what this tool is not

CASS is Coding Accuracy Support System, the USPS certification programme for address-matching software. A vendor submits its software against a USPS test file of addresses with known correct results; passing at the required accuracy earns certification, renewed annually. CASS-certified software is what produces:

• a confirmed match against the USPS address database,
• the correct ZIP+4 and delivery point digits,
• DPV (Delivery Point Validation) — whether that exact point receives mail,
• LACS and SuiteLink corrections, where streets have been renamed or renumbered,
• the RDI flag distinguishing residential from commercial,
• and a Form 3553, which is what qualifies a mailing for presort postage discounts.

Those discounts are the commercial reason CASS exists. If you are mailing at volume, you need certified processing; the saving pays for it.

This site is not CASS-certified and does not verify addresses. Specifically, it does not:

• confirm that a generated or submitted address exists,
• confirm that mail would be delivered to it,
• produce a real ZIP+4 (the add-on is derived from the USPS database, and a generated one is four valid-looking digits pointing nowhere),
• return DPV, RDI, LACS or SuiteLink results,
• qualify anything for postage discounts.

What it does do is generate records whose city, county, state, ZIP prefix and area code hold together, so your validation layer accepts them and your test exercises the code you meant to test rather than your own fixture being rejected. For production verification, use a CASS-certified provider or the USPS Web Tools APIs directly.

Implementing this without getting it wrong

• Standardise on write, store both forms. Keep what the customer typed and the canonical form. When a carrier disagrees with your standardisation you will need the original to see why.
• Never auto-correct silently. If standardisation changes the meaning — moving a directional, dropping a unit — show the user the result and let them confirm. Silent correction is how parcels go to the wrong building.
• Do not reject on a ZIP-city mismatch. Flag it. The address is more often right than your table.
• Keep a fixture set of the awkward cases: a rural route, an APO address, a unique ZIP, a hyphenated unit, a street named for a direction, a PO Box and street address in one record, an apostrophe in a name. These are the ones real customers submit and uniform generators never produce.
• Treat ZIP+4 as derived, not stored. Re-derive it when you need it; add-ons get reassigned.

To check what a five-digit code resolves to, or to see which prefixes belong to a state, use the ZIP code lookup.