Forgiving format

A forgiving format moves the work of tidying an answer from the person to the program. The reader types a phone number the way they say it, with spaces or dashes or a country code, and the field takes it, strips what it does not need, and stores one canonical form. The rejection that would have happened, “please enter a valid phone number”, was never about validity. The digits were all there and in the right order. The form simply wanted them punctuated its way and made that the reader’s problem.

The engineering version of the rule is older than the web: be liberal in what you accept and conservative in what you send. The design version is easier to apply. Parse, do not police. Ask what the value means, extract that, and let everything else go: whitespace, punctuation, letter case, a leading plus, a pasted string that arrived with a currency symbol attached. Search is the same instinct applied to queries, and a date field that takes “next tuesday” is the same courtesy at the far end of the scale. What separates this from sloppiness is the second half of the sentence. Accept liberally, then normalise to exactly one stored shape, and show the reader what you stored so the leniency never turns into a guess they cannot see.

Its close relative is the input mask, which solves the same problem from the other end by supplying the punctuation itself as you type. A mask is the better answer where the shape genuinely is fixed and familiar, a card number or a local phone number, and where the template also tells the reader how long the answer is. It is the worse answer where the shape varies by country or by format, because a mask that insists on one arrangement rejects the correct value typed a different way, and it has to fight the caret to do it. Where a mask is right, a forgiving parser still belongs underneath it, because a paste arrives already punctuated.

Strictness earns its place in a few named cases, and they are narrower than most forms assume. A code that must be transcribed exactly, a checksum, an IBAN, a licence key: these deserve chunking for legibility and a real check afterwards, not a shrug. Everything else gets the courtesy. Do the tidying silently rather than announcing it, keep the raw value if the reader may need to correct it, and reserve the error message for input that is genuinely missing or genuinely wrong, which is the only kind anybody can act on.