Postel's law

Postel's law, also known as the robustness principle, comes from internet pioneer Jon Postel's early protocol specifications. RFC 761 (TCP, January 1980) states it as "be conservative in what you do, be liberal in what you accept from others", and RFC 760 (IP, same month) has a similar line. RFC 1122 later gave the familiar wording: "Be liberal in what you accept, and conservative in what you send". In UX, it is applied to how products handle what people type, paste, upload and say.

Why it matters

People enter information in many shapes. Phone numbers come with spaces, dashes or country codes. Dates come as "3 Oct", "10/03" or "next Friday". Names include apostrophes and accents. An interface that rejects anything outside one exact format pushes the work of conforming onto the user, and every rejection is a small failure. Being tolerant on input and consistent on output makes products feel forgiving without becoming unpredictable.

How to apply it

• Do accept common variations and normalize them yourself: strip spaces from card numbers, accept pasted values with stray whitespace, parse dates in several formats.
• Do show what you understood. If you interpret "next Friday" as a specific date, display that date so people can catch a misreading.
• Do set clear limits and explain them in plain language when input truly cannot be accepted.
• Do keep output strict: consistent formats, predictable structure, stable behavior.
• Don't validate for a format you could convert to automatically.
• Don't silently guess on input where a wrong guess is costly, such as payment amounts or recipients. Ask.

Common mistakes

The main caveat comes from the protocol world itself. RFC 9413 (June 2023), from the Internet Architecture Board, argues that tolerating bad input lets errors spread and become entrenched, "forcing other implementations to be tolerant of those errors". It recommends active maintenance of protocols, and in a section called "Virtuous Intolerance" notes that choosing fatal errors over silent recovery "can ensure that faults receive attention". The UX equivalent: silent acceptance can hide problems from both the user and your team.

• Accepting input without confirming the interpretation, so mistakes surface much later.
• Being liberal in output too, such as inconsistent date formats across screens or vague confirmations.
• Treating tolerance as a security model. RFC 1122 itself warns that software should assume some input is malicious. Accepting varied input still requires validating and sanitizing it.

In AI products

AI interfaces lean hard on the liberal half of the law. A chat assistant accepts messy, misspelled, half-finished prompts in any language and usually does something sensible with them. That is a real usability gain over rigid forms and command syntax.

The conservative half is where many AI features fall short. When AI output feeds other systems or decisions, such as an extraction tool filling a spreadsheet or an agent filling a booking form, it should be strict: validated against a schema, consistent in format, and clear about what it could not determine instead of filling gaps with plausible guesses. Liberal acceptance also has a security edge in AI: text from documents, web pages or emails may contain instructions meant to manipulate the model, so treat it as untrusted and use guardrails around what the system will act on.