Laws of UX
Postel's Law (Robustness Principle)
Be liberal in what you accept from users; be precise in what you give back.
Where it comes from
It comes from the early architecture of the internet. Jon Postel, an engineer who shaped foundational protocols like TCP, wrote in 1980 that an implementation should be 'conservative in what it does, liberal in what it accepts'. The robustness principle has since travelled from networking into interface design.
Why it matters for your website
Accept what people naturally give you; return exactly what they need. Postel's Law says systems should tolerate variable input. Forms that reject common formats, searches that punish typos, and fields that demand rigid conventions all push your system's limitations onto the user.
Applied to users, the law splits into two commitments. Be generous about the input you accept — spaces in card numbers, different date formats, a missing 'http://' — and be precise and dependable about the output you return. Every format your form rejects is a moment where the user did nothing wrong but is told they did.
The cost of rigidity is invisible in testing and brutal in the wild, because the people who hit it are mid-task and motivated. A phone field that won't take the number the way it's written on the user's own card doesn't protect data quality; it just adds a step, an error message, and a reason to give up.
Wrong vs right
A card-number field that rejects spaces, forcing the user to delete the grouping they naturally typed.
A field that accepts the number however it's entered and strips the spaces itself.
A date input that demands one rigid format (MM/DD/YYYY) and errors on anything else.
An input that parses common date formats, or a picker that removes the ambiguity entirely.
A search that returns nothing for a minor typo or a plural, punishing the user for an obvious near-match.
A search that tolerates typos and variations, returning the result the user clearly meant.
Understanding Postel's Law (Robustness Principle)
Postel's Law — the robustness principle — began as advice for networked systems: be conservative in what you send, liberal in what you accept. Translated to user experience, it becomes a principle of forgiveness. Accept input in whatever reasonable form people naturally provide it, and do the work of interpreting it, rather than demanding they conform to your system's internal preferences.
The 'liberal in what you accept' half is where most of the practical wins live. People type phone numbers with spaces, dates in local formats, names with accents, URLs without protocols. A forgiving system absorbs all of this and normalises it quietly; a rigid one throws errors and makes the user retype. Since the user is usually mid-task and motivated, each needless rejection is a real risk of abandonment.
The 'conservative in what you send' half matters too: what your system returns — confirmations, data, responses — should be precise, predictable, and well-formed, so whatever consumes it can rely on it. The pairing is a kind of generosity with a backbone: forgiving at the edges, dependable at the core. It connects to error prevention, error recovery, and inline validation.
How Kweri checks it
Kweri can detect some signs of input rigidity from the page — for example fields with strict format constraints or validation that appears to reject common variations. But fully testing how forgiving a system is means submitting many input variants and watching how it responds, which goes beyond a static review. So Kweri flags likely points of unnecessary rigidity and prompts you to check them, while being clear that confirming true robustness needs hands-on testing of real input.
FAQ
What is Postel's Law?
Postel's Law, or the robustness principle, states: be conservative in what you do, and liberal in what you accept from others. In UX it means accepting user input in whatever reasonable form it comes, while returning precise, dependable output.
Who was Postel's Law named after?
Jon Postel, an engineer central to the early internet who helped define core protocols like TCP. He stated the robustness principle in 1980; it was later applied to design and popularised through Jon Yablonski's Laws of UX.
How do I apply Postel's Law to forms?
Accept input flexibly: allow spaces and dashes in numbers, parse multiple date formats, tolerate missing protocols in URLs, and forgive common typos in search. Normalise the input behind the scenes rather than rejecting it and asking the user to retype.
Why is rigid input validation a problem?
Because it blames the user for doing nothing wrong. Rejecting a card number because it contains spaces, or a date because of its format, adds friction and error messages at exactly the moment the user is trying to complete a task — a common cause of abandonment.
Does being liberal in what you accept mean accepting bad data?
No. It means accepting the many valid forms people naturally use and normalising them, while still validating genuinely invalid input. The aim is to forgive formatting differences, not to skip real validation.
Related principles
Stop problems before they happen — that beats even the best error message.
Error messages should be plain English, name the exact problem, and suggest the fix.
Errors should be flagged as users complete each field, not after the entire form is submitted — post-submit error discovery forces users to stop, hunt for problems, and often repeat work they've already done.
Attribution & sources
Identified by Jon Postel (1980). Catalogued from Laws of UX (Jon Yablonski).
The robustness principle, from Jon Postel's early internet protocol work; popularised for designers by Jon Yablonski's Laws of UX.
See Postel's Law (Robustness Principle) on your own site
Run a free Kweri audit — a plain-English review of your site’s speed, accessibility, SEO and design, ranked by what to fix first. No login, no jargon.
Run a free audit →