Why Postal Codes Should Be Strings in JSON and Databases

A postal code is an identifier. Treating it as a quantity creates unnecessary conversions: leading zeros disappear, separators get removed and alphanumeric values cannot be represented. A text field gives an application room to preserve the submitted value.

Compare the payloads

{"postalCode":"00100"}
{"postalCode":100}

These are deliberately different test inputs. The first preserves five characters; the second contains a number. If your API requires a string, reject the numeric input with a clear field error rather than silently guessing what the user meant. This is a proposed API contract, not a claim about every address API.

Find the first destructive conversion

When a value loses zeros, compare the input control, submitted request, stored record, API response and downloaded file in that order. Fix the first step that changes the value. Formatting a damaged number to five digits at the end can hide the original bug and incorrectly modify other countries' values.

A small regression set

These values exercise storage behavior; the table does not assert that each value is assigned or appropriate for any particular destination. Test country-specific validation separately.

Define normalization deliberately

Decide whether your application trims surrounding whitespace or changes letter case. Document the expected output for each input. Keep the original value where your workflow needs an audit trail, and avoid removing all punctuation with a global replacement. An internal space may be useful in the display format.

For a concrete country example, use the Finland address generator and compare the copied value with the saved result. Passing a round-trip test proves preservation, not a match between a street and a real postal delivery point.

Further reading

English address field guides provide country-specific examples and postal references.