Loading…
Loading…
Be liberal in what you accept, conservative in what you send.
stellae.design
Postel's Law — 'be conservative in what you do, be liberal in what you accept' — means designing interfaces resilient to real human behaviour: typos, unexpected formats, different devices, and varying abilities. Tolerance reduces friction; bounded validation ensures safety.
Be conservative in what you do, be liberal in what you accept from others. In UX terms: accept varied input gracefully, normalise it helpfully, and validate strictly where security and correctness require it.
Type a date in any format. The system accepts liberally and normalizes the output.
Be liberal in what you accept (any date format), conservative in what you produce (consistent output).
Phone input accepting any format
Accepts (415) 555-1234, 415-555-1234, 4155551234 — all valid
Phone input requiring exact format
Rejects valid numbers that don't match a specific pattern like XXX-XXX-XXXX
The robustness principle originated in TCP (RFC 793) and was formulated by Jon Postel. The behavioural reality behind it isn't a single cognitive bias — it's the variance in human attention, motor control, learning, and context. People mistype, use unexpected formats, arrive on different devices, and have different abilities. Modern protocol guidance (RFC 9413) adds that tolerance has trade-offs: accepting ambiguous input can create interoperability drift and security risk if unbounded.
Google Search accepts misspelled queries, incomplete phrases, and natural language questions — then returns useful results regardless. The system is maximally liberal in what it accepts from users while being precise and structured in what it returns. This tolerance is a textbook application of Postel's Law to search interfaces.
Stripe's payment forms accept credit card expiration dates in multiple formats — '01/25', '1/25', '0125', and 'January 2025' — and normalize them behind the scenes. Users don't need to guess the expected format, reducing form errors and abandonment. The strict output is a standardized date, regardless of the liberal input.
Early XML parsers would reject entire documents for a single missing closing tag or attribute quote. While technically correct, this strict input handling frustrated developers and slowed adoption compared to HTML's forgiving parser. The rigid rejection of imperfect input violated Postel's Law and created a poor developer experience.
Slack accepts Markdown, plain text, pasted rich text, and emoji shortcodes in the same input field, rendering them all appropriately. Users can format messages however feels natural without learning a specific syntax. The output is consistently rendered rich text, regardless of the varied input methods.
• Applying Postel's Law as 'accept anything' without clear feedback when input is transformed or rejected.
• Designing an overly 'forgiving' UI that hides errors until the end, creating large correction cost.
• Tolerance without security: silently processing malformed or malicious input.
| Check | Good Pattern | How to Test |
|---|---|---|
| Input format flexibility | Forms and inputs accept multiple reasonable formats (dates, phone numbers, addresses) and normalize them behind the scenes rather than rejecting non-standard entries. | Enter the same information in five different valid formats across all input fields. Verify that all are accepted and correctly normalized to the system's canonical format. |
| Error message helpfulness | When input cannot be accepted, error messages explain what was expected and how to fix it — not just that it was wrong. | Intentionally submit malformed data in every input field. Check that each error message includes the expected format, an example, and a clear path to correction. |
| Output consistency | System outputs (API responses, exports, displays) follow a strict, documented format regardless of input variation. | Submit varied inputs and verify that all outputs conform to the documented schema. Run outputs through a validator to confirm strict formatting compliance. |
In safety- and security-critical contexts (authentication, payments, permissions), strictness is ethical and safer. Modern protocol guidance stresses balancing robustness with security. Be tolerant in user help, but strict in system acceptance.
Was this article helpful?