Postel's Law
Postel’s Law is the internet engineering habit of tightening what you emit and loosening what you tolerate on input. It shows up everywhere you care about compatibility across versions, vendors, or sloppy clients.
Be conservative in what you do, be liberal in what you accept from others.
That line is often shortened to “be conservative in what you send, liberal in what you accept.” Jon Postel baked it into early protocol text. The January 1980 RFC 760 Internet Protocol standard puts it in plain terms for implementations. Send well-formed datagrams, but if you can interpret a datagram without ambiguity, accept it instead of faulting the peer for minor deviations.
APIs
Treat your public request and response bodies as contracts you keep in strict form. Validate outbound serialization so you never ship a field shape you would reject on the way back in. On ingest, decide which deviations are harmless (unknown JSON keys, redundant whitespace, a legacy enum spelling) and which are unsafe or ambiguous. Document the difference so the next maintainer does not “helpfully” tighten the parser and break a cohort you forgot existed.
Parsers
Lexers and decoders are the sharp end of the law. A forgiving parser keeps old files and odd-but-clear inputs working. A too-forgiving parser hides bugs until they land in a stricter consumer or a security boundary. Pair liberality with explicit normalization (canonicalize after parse, log what you repaired) so weirdness does not become state you cannot explain.
Compatibility
Interoperability is a social outcome, not a compiler pass. When you accept sloppy input long enough, that slop can ossify into what everyone expects. New strict implementations then look broken until they replicate the old mistakes. The IAB discussion in RFC 9413 is worth reading when you are designing something safety-critical. The move there is not “never be liberal” but “know what you are buying when you are liberal,” especially across trust boundaries.
Use Postel’s Law as a default for human-facing integration surfaces and version churn. The wrappers you build on top still obey the law of leaky abstractions. Liberal input does not remove the need to understand what peers actually sent. Reach for strictness when the threat model, compliance rules, or determinism requirements say the cost of ambiguity is too high.