Postel's Law: Liberal With What You Receive, Strict With What You Send
Postel's law says to accept imperfect input and send consistent output. What it means for forms, its limits, and why Internet engineers revisited it.
What does Postel’s law say?
The classic phrase is “Be liberal in what you accept, and conservative in what you send”. It is attributed to Jon Postel, an Internet pioneer, who wrote it into the early IP and TCP specifications in the late 1970s and early 1980s. His original wording was “be conservative in what you do, be liberal in what you accept from others”. Protocols had to work together across implementations made by different vendors, and this rule kept one out-of-spec detail from breaking communication (Wikipedia, “Robustness principle”).
Laws of UX adapts it to interaction with people. Its version says that receivers should accept input that doesn’t match the exact format as long as its meaning is clear, and that flexibility should have defined limits and clear feedback (Laws of UX, “Postel’s Law”).
Why should a designer care?
Because forms are where people get punished most for writing differently from how the system expects. A phone number with spaces, a date written in another order, or an email in capitals can block a sign-up for no real reason. Postel’s law asks you to check whether the error belongs to the user or to your rule.
In practice, this means the system does the work of converting input into what it needs: accepting dates in several formats, letting the phone number be typed freely and formatting it afterwards, or accepting emails with different valid structures. Laws of UX frames it the same way: accept varied input, translate it into what your system requires, and give clear feedback.
How do you apply it in a form?
A practical rule: tolerate the form, validate the meaning.
- Accept format variants. If the field asks for a phone number, accept it with and without spaces, with or without a prefix. Format afterwards.
- Don’t punish capitals or extra spaces. Trim spaces and normalize what doesn’t change the meaning.
- Correct when the result doesn’t change. If the person typed “Madird”, you can suggest “Madrid”. If the data would change, ask. To decide when to prevent an error and when to recover from it, the page on prevention vs. recovery of errors gives you the framework.
- Give clear errors when input can’t be interpreted. A message that says what is missing and how to fix it beats “invalid format”.
- Keep output consistent. What you store, what you send to another system, and what you show should follow a single format.
Search engines that correct typos or browsers that complete an incomplete URL work with this logic.
What are its limits?
Flexibility has limits, and the technical community itself has debated them. RFC 9413, written by Martin Thomson and David Schinazi and published by the IAB in 2023, separates three things: defects, attacks, and unexpected input. It argues that tolerating unexpected input is no longer best practice in every case. It also describes “protocol decay”: a tolerated error starts being relied on, and then every implementation has to copy it. It concludes that ignoring faulty or ambiguous input is almost always the wrong solution (RFC 9413).
The document’s proposal is active protocol maintenance: revising specifications together with implementations to reduce ambiguity over time, instead of relying on tolerance (IAB, “RFC 9413 on maintaining robust protocols”). Wikipedia also records security criticism, such as a 2018 paper showing the principle could be exploited in the Tor routing protocol.
For design, the lesson is similar: tolerating is not the same as guessing. A password that is loosely “interpreted”, an amount that is silently rounded, or an email silently corrected to another domain are cases where the system hides a problem instead of solving it.
Example
Illustrative example: a payment form asks for a card’s expiry date in MM/YY format. A person types “3/27”. A strict form rejects it with “invalid format”. A tolerant one reads it as March 2027, shows it formatted as “03/27”, and asks for a visual confirmation before submitting. Now imagine they type “27/3”. There the interpretation isn’t safe: the form shows a clear error saying the month goes first. The rule is the same, but the system only guesses when the meaning leaves no doubt.
When NOT to apply it
- In sensitive or critical data. Passwords, amounts, and identifiers must not be corrected silently.
- When the correction changes the meaning. If “Ana Lopez” could be “Ana López” or a different person, don’t change it without asking.
- When the system needs an exact format. A verification code or an account number admits no interpretation.
- As an excuse not to define rules. Tolerating without clear rules is improvising, not designing.
Common mistakes
- Rejecting valid input over a space or a capital letter.
- Correcting data without telling the person.
- Showing generic errors that don’t say how to fix them.
- Storing the data in one format and displaying it in another.
- Confusing tolerance with a lack of validation.
How to start tomorrow
Open the form with the most abandonment in your product and list the fields that reject an entry. For each one, ask whether the error is real or just about format. If it’s about format, accept the variant and normalize it. If it’s real, leave a message that says what is missing. Review how the data is stored and how it is displayed too. If validation timing is a concern right now, the piece on form validation timing helps you decide when to warn. And for fields that format while you type, see the dangers of input masking. If the error message appears after submitting, also review how it is shown in notifications and toasts, because a message that disappears by itself is no help when someone has to fix a value.