Validating and Storing Canadian Postal Codes

Canadian postal codes are one of the more validatable address fields in the world. The pattern is rigid, six letters are forbidden outright, and the shape never varies. That makes the common failures all the more irritating, because almost all of them are avoidable.

The pattern, precisely

Letter, digit, letter, space, digit, letter, digit. Six characters plus a space, always, with no shorter or longer form and no optional extension. Written in capitals.

On top of the shape, the letter set is restricted. D, F, I, O, Q and U never appear anywhere, and W and Z never appear as the first character. Encoding those into your check costs nothing and catches a genuine class of typing error — somebody reaching for O instead of zero — at the moment it happens rather than at the moment a parcel fails.

Mistake one: dropping the space

The official format puts a space between the two groups of three. M5V2T6 points at the same place and is not the form Canada Post records use, so it will not match cleanly when compared against another system.

Normalising is easy because the shape is fixed: strip all whitespace, uppercase, then insert a space after the third character. There is no ambiguity about where it goes, which is a luxury the UK format does not offer.

Mistake two: sanitising the space away

A shared input-cleaning function that strips non-alphanumeric characters will remove the space, and it will usually have been written for a different field entirely. Trimming the ends is correct; removing whitespace everywhere is not. This is a very common way a correct value is damaged between the browser and the database.

Mistake three: the province shortcut

Deriving a province from the first letter is tempting and unreliable. Quebec and Ontario each span several letters, and the Northwest Territories and Nunavut share one. A system that infers the province will be right nearly always, which is exactly why the failures go unnoticed until something that depends on the province — a tax rate, a shipping zone — is wrong for a real order.

Mistake four: expecting a valid code to exist

A pattern check tells you a value has the right shape. It cannot tell you the code has been issued or that the address is real. A great many structurally perfect postal codes correspond to nothing at all.

There is a middle option worth knowing about if a full address service is more than you need. Canada Post publishes the list of valid forward sortation areas, which is small, stable and freely available. Checking that the first three characters are a real FSA costs you nothing at runtime and catches a whole class of fabricated or mistyped values that a pattern check waves through.

If correctness matters — a shipment, a legal record, anything with a cost attached to being wrong — verify against a real lookup rather than a regular expression, and let the user override the result. Lookups lag new construction, and a form that refuses an address because its data has not caught up turns away genuine customers.

Mistake five: rejecting rural and box addresses

A code with a zero in the second position covers a wide rural region, and its delivery unit often describes a rural route or a run of post office boxes rather than street delivery. Address forms that insist on a street name and number reject those customers outright, and they are real customers with entirely valid addresses.

If you ship, the related problem is worth handling deliberately rather than discovering at the warehouse: some carriers do not deliver to post office boxes at all. Detecting the rural zero early lets you say so at checkout, which is a far better experience than an unexplained refund two days later.

Mistake six: assuming codes never change

Canada Post creates and reassigns codes as housing is built and routes are reorganised. A code captured a few years ago may no longer be current, which matters if you revalidate addresses in bulk: a non-trivial share of perfectly good historical records will fail a fresh check. The correct response is to flag them for confirmation, not to delete them.

The ZIP code field

International forms frequently label the field ZIP code and sometimes validate it as five digits. A Canadian postal code has letters in it and cannot be made to fit.

Where the field simply carries an American label but accepts anything, enter your postal code in full with the space and in capitals. Where it enforces five digits, there is no correct value to type, and the usual workarounds all produce an address a carrier cannot deliver against. Look for a country selector before the address fields, since many forms switch validation when the country changes, or use a different route to the purchase.

The rules worth enforcing

• Store as text. Nothing about a postal code is numeric.
• Uppercase on input and keep the space after the third character.
• Check the alternating letter-digit pattern and reject the six excluded letters.
• Allow seven characters of storage, six plus the space.
• Do not derive province, city or tax region from the code.
• If it must be correct, verify it rather than pattern-match it.

What to do with the codes you already have

Most teams discover these rules with a table full of postcodes already in it, in several shapes at once. Resist the urge to run one bulk update and move on.

Normalising case and spacing is safe, because neither changes which addresses the code points at. Deleting or rewriting values that fail a pattern check is not — your pattern is more likely to be wrong than a postal code a real customer typed, and a code Canada Post has since reassigned is still the best record you have of where somebody lived.

The useful middle path is to normalise the safe things, flag the rest for confirmation the next time that customer is in touch, and leave the data alone otherwise. A record that needs checking is more valuable than one you have tidied into nothing.

A note on display

Store one canonical form and render it consistently. Mixed case and missing spaces across a set of customer records make deduplication harder than it needs to be, and they make exported data awkward for whoever receives it — a carrier, an accountant, a mailing house.

Uppercase with a single space is the form Canada Post uses, so it is the form worth standardising on. Doing that normalisation once on input is far cheaper than doing it in every query, report and export afterwards.

Pick the canonical form once, write it down where the next developer will find it, and enforce it at the single point where addresses enter the system rather than in each feature that touches them afterwards.

For the reasoning behind the letter rules, see the six letters a postal code never uses. For what each half of the code means, see FSA versus LDU. And to get your own code without typing an address, you can find it from where you are.