How to Validate Postal Codes and ZIP Codes in a Pasted List

I keep a running list of address exports that arrive from three different CRMs, two support inboxes, and the occasional spreadsheet someone copied out of a web page. Before any of it goes into a label print run, every postal code needs to be checked. Not "looks roughly right" — actually checked, row by row, with a note on why a row failed. That is the exact job the Postal Code List Validator does: you paste the text or drop a local file, and it hands back a pass/fail report with a reason printed beside every entry.

The trap that bites people is assuming a postal code is a postal code. It is not. The format depends entirely on the country, and a code that is perfectly valid for one country is garbage for another.

Postal code formats are country-specific

This is the single fact that makes postal-code cleanup harder than it looks. There is no universal pattern. A few examples that I run into constantly:

United States: five digits, like 90210. The extended ZIP+4 form adds a hyphen and four more digits, like 90210-1234.
United Kingdom: alphanumeric, with a space splitting the outward and inward halves, like SW1A 1AA. Letters and digits mix in positions a US-only check would reject outright.
Canada: strict alternation of letter and digit in two groups, like K1A 0B1. No D, F, I, O, Q, or U in certain positions, and never an all-digit string.

So K1A 0B1 is a valid Canadian code and an invalid US one. 90210 is a clean US ZIP and a nonsense UK postcode. Validation only means something once you have decided which country's rules apply to the list in front of you. If you mix codes from several countries in one column without separating them first, you are going to get false failures no matter what tool you use — that is a data problem, not a validator problem.

What this tool actually checks

To be precise about scope: the Postal Code List Validator treats each line of your input as one candidate postal code and runs it through the parser entirely inside your browser tab. It reads pasted text — logs, CSV exports, copied HTML, support tickets, Markdown notes — and it reads uploaded local text files through the File API. Nothing is sent to a server. The output is a per-row report: each entry is marked pass or fail, and every failed row carries the reason it was flagged, such as a code that is one digit short or one that has a letter where a digit belongs.

It is a list-cleaning and reporting tool, not a delivery-database lookup. It will tell you a row does not conform to a postal-code shape and why. It will not confirm that the address is real, deliverable, or currently in use. Those are different jobs, and the tool's own notes are blunt about that: a correctly formatted code is not proof that the place exists.

A worked example

Say I paste this list, straight from a support export:

94105
9410
K1A 0B1
SW1A 1AA
1000A0
10001

The report comes back like this:

| Input | Status | Reason | |---|---|---| | 94105 | pass | OK | | 9410 | fail | too short — four characters where five are expected | | K1A 0B1 | pass | OK | | SW1A 1AA | pass | OK | | 1000A0 | fail | letter where a digit belongs | | 10001 | pass | OK |

The two failures are the entire point. 9410 is a five-digit ZIP with a digit dropped — exactly the row you hand back for repair instead of quietly deleting to make the pass count look better. 1000A0 slipped a letter into a numeric slot. Both stay in the report, with their reasons, so you can fix them at the source rather than discovering the gap after the labels print.

Cleaning the list end to end

A raw paste is rarely ready to ship, so the tool does more than flag. You can keep unique rows only when an export has duplicate codes, or preserve every invalid row for review when you need the full audit trail. You can sort the normalized output so the result is stable and diffable. And you can switch the output format between plain lines, CSV, JSON, Markdown, SQL IN, and a TypeScript union, then download the exact artifact your next step needs — a CSV for a CRM import, a SQL IN clause for a quick query, a JSON blob for a script.

One habit worth keeping: copied web text often carries hidden whitespace that makes two identical-looking codes register as different rows. Normalize before you deduplicate, or you will carry phantom duplicates into the import. When you need something an auditor can follow, download the CSV or Markdown with line numbers rather than copying only the final clean list — the line numbers are what let you trace a flagged row back to where it came from.

If your raw data needs heavier surgery first — stray columns, inconsistent line endings, codes buried inside other text — it is usually faster to pull the postal-code column out before validating. The Postal Code Extractor is built for that pre-step: it lifts codes out of messy text so the validator sees a clean one-per-line list. From there, Postal Code Normalizer standardizes spacing and case, and Postal Code Deduplicator collapses the repeats. They share the same local-only engine, so your data never leaves the tab across the whole pipeline.

When to reach for it

The honest answer is: right before anything irreversible touches the list. Before a label print run. Before a bulk address import into a CRM or ticket system. Before an allowlist or redirect map goes live. Those are the moments where a one-character typo turns into a returned package or a broken record, and they are cheap to catch beforehand and expensive to catch afterward.

It is not built for multi-gigabyte raw dumps — a few thousand codes is the realistic scale, and a few megabytes is plenty. If a check feels slow, that is usually a sign the input is a full export that should have been cut down to the postal-code column first. Trim it, paste it, read the reasons, fix the failures, and download the clean artifact. That is the whole loop, and it stays in your browser from start to finish.

Start with the Postal Code List Validator, and pair it with the extractor when the source text is messy.

Made by Toolora · Updated 2026-06-13