Postel's Law

The law

Accept what people give you in as many reasonable forms as you can, and be strict about what you give back.

In design the law is about input and output. People type dates, phone numbers and names in many ways; a robust product understands them. What the product shows in return should always be in one clear, consistent form.

Where it comes from

Jon Postel edited the early specifications of the internet's core protocols. In the TCP specification, RFC 761, published in 1980, he wrote the robustness principle that now carries his name: be conservative in what you do, be liberal in what you accept from others. It told engineers to send strictly correct messages while tolerating small deviations in the messages they received, so that machines built by different teams could still talk to each other.

RFC 1122 restated the principle in 1989. Designers later borrowed it for the interface between people and software, where the "other implementation" is a person typing.

What it means for an interface

• Parse, do not police. Accept "12/03", "12 March" and "March 12" when the meaning is clear, and confirm the interpretation instead of rejecting the input.
• Normalize on the way in. Strip spaces from card numbers, ignore case in email addresses and trim stray whitespace before validating.
• Output one format. Once the product understands the value, show it back in a single, consistent format so people can check it at a glance.
• Ask when it is genuinely ambiguous. Liberal acceptance stops where guessing could be wrong. "03/04" can be two different dates; show which one you understood.

Examples

Phone numbers. A field that accepts "+55 11 91234-5678", "(11) 91234 5678" and "11912345678" and stores them all the same way avoids a common source of failed forms. A field that rejects dashes makes people guess the rule.

Search. Search that tolerates typos, plurals and different word order follows the law. People rarely type the exact term the catalogue uses.

Payment cards. Card fields that accept the number with or without spaces, then display it grouped in fours, are liberal on the way in and strict on the way out.

Where it is misapplied

• Accepting invalid data silently. Liberal input does not mean storing nonsense. Interpret what you can, confirm it, and refuse what you cannot understand with a clear message.
• Guessing on high-stakes input. Money amounts, dosages and dates of birth deserve confirmation, not a quiet best guess.
• Inconsistent output. A product that accepts many formats and also displays many formats leaves people unsure what was saved.
• Security shortcuts. Engineers have criticized the original principle because tolerant parsers can be exploited. Normalizing input is fine; skipping validation is not.

Checklist

• Forms accept the common formats people actually type for dates, phones, cards and names.
• Input is normalized before it is validated.
• Every accepted value is shown back in one consistent format.
• Ambiguous input is confirmed, not guessed silently.
• Error messages say which formats work instead of only saying the value is wrong.

Related

• Tesler's Law: parsing messy input is complexity the product absorbs.
• Jakob's Law: people type values the way other products taught them to.
• Patterns: Inline Validation.