Jon Postel, writing an early TCP specification, laid down a rule that shaped how the internet's protocols were built: be conservative in what you do, be liberal in what you accept from others. For decades it was treated as unambiguous wisdom. Today good engineers know it's a trade-off with a sharp edge, and knowing when to break it is the interesting part.
Key Takeaways
- Postel's Law: be conservative in what you send, liberal in what you accept (robustness principle).
- It made early protocols interoperable by tolerating small incompatibilities (Postel's Law).
- Modern critics argue over-liberal acceptance masks errors and creates security and maintainability risk (the anti-robustness case).
- The senior move is knowing which half of the rule to apply where.
What the Rule Says
Postel's formulation, from the 1980 TCP spec, splits behavior in two (robustness principle). On output, be strict: send only well-formed, standards-compliant data, nothing weird. On input, be forgiving: accept anything whose intent is clear, even if it bends the spec. The goal was interoperability in a young, messy network where every implementation had quirks. If everyone tolerated everyone else's small mistakes, the whole system kept working instead of shattering on the first deviation (Postel's Law).
It worked. The robustness principle is a real reason the early internet interoperated at all, across dozens of incompatible implementations built by people who never coordinated.
Why Modern Engineers Push Back
Here's the edge the classic version hides. Being liberal in what you accept has compounding costs that show up years later (the anti-robustness principle). Every quirk you tolerate becomes a quirk someone now depends on, which is Hyrum's Law in action: once your parser accepts malformed input, malformed input is now part of your de-facto contract, forever. Liberal acceptance also lets sloppy producers proliferate, because there's no pressure to fix their output when everyone accepts it. And in security terms, cheerfully accepting malformed input is exactly how injection and parsing attacks get in.
So the modern consensus tempers Postel: be strict on output still, but be deliberately strict on input too, rejecting malformed data loudly and early rather than guessing at intent.
| Postel's original | The modern temper |
|---|---|
| Strict output | Strict output (unchanged) |
| Liberal input | Strict input, fail loudly |
| Maximize tolerance | Maximize clarity + security |
| Great for bootstrapping | Better for maintaining + securing |
A Concrete Version
A team builds an API that "helpfully" accepts dates in a dozen formats, missing fields filled with defaults, and extra fields silently ignored, all in the spirit of being liberal. It works beautifully at first. Two years later, three client integrations depend on quirks of the lenient parsing, a security review finds an injection path through the flexible input, and nobody can tighten the API without breaking someone. A stricter API that rejected bad input on day one would have been mildly annoying early and vastly cheaper later.
The Honest Counterpoint
The critics can overshoot too, and strict-everything has its own failure mode. In genuinely uncoordinated ecosystems, browsers rendering the world's HTML, email, systems that must talk to legacy clients you'll never control, some liberal acceptance is unavoidable and correct, because rejecting everything imperfect means talking to no one. Postel's Law earned its place; the mistake is applying it reflexively inside your own controlled systems, where strictness is cheap and the producers are your own teammates. The judgment is contextual: liberal at the ragged edges you don't control, strict everywhere you do.
What This Means for Teams
Postel's Law is a good example of why "best practices" need judgment rather than obedience. A junior applies the rule as gospel; a senior asks whether this interface is a controlled internal boundary (be strict) or a wild external one (be pragmatic). That contextual judgment about interface design, and its long-term maintenance and security consequences, is exactly what we screen for in how to verify a senior engineer, and it connects to the same understand-before-you-change instinct. See available engineers.
Frequently Asked Questions
What is Postel's Law?
The robustness principle from Jon Postel's early TCP work: be conservative in what you send, liberal in what you accept. It aimed to keep a messy young network interoperable by tolerating small incompatibilities.
Why do modern engineers criticize it?
Because liberal acceptance masks errors, lets others depend on quirks (Hyrum's Law), allows sloppy producers to proliferate, and opens security risk. Many now favor strict input validation that fails loudly.
So should I always be strict?
No, it depends on the boundary. Be strict on interfaces you control (your own services), and accept some liberality at genuinely uncoordinated edges like browsers or legacy clients you can't change.
How does this relate to Hyrum's Law?
Directly. Anything your system accepts, including malformed input, becomes something a consumer will depend on. Liberal acceptance quietly expands your real contract and makes future tightening a breaking change.
The Bottom Line
Postel's Law built the internet by making systems tolerant, and that same tolerance became a liability once systems needed to be secure and maintainable. Keep the strict-output half always. Apply the liberal-input half only at the ragged edges you don't control, and be deliberately strict everywhere you do. The rule is a tool, not a commandment.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers, with a vetted shortlist in 72 hours. See available engineers.
