Postel's Law

Postel's Law is one of the most influential and contested principles in software engineering. Its familiar phrasing, "be conservative in what you send, be liberal in what you accept", helped define the early posture of Internet protocol design. The rule made practical sense in a young network of diverse machines and independently developed implementations. Yet the same tolerance that enables short-term interoperability can create long-term instability when systems silently accept errors that senders never need to correct.

What Postel's Law says

Postel's Law is also known as the Robustness Principle. It directs implementations to be conservative in sending behavior and liberal in receiving behavior. RFC 1122 states the principle as: "Be liberal in what you accept and conservative in what you send", presenting it as a general rule for protocol layers that can improve robustness and interoperability1.

The principle is associated with Jon Postel and earlier TCP specifications. In practical terms, a sender should create messages that comply with the protocol precisely, while a receiver should recover from minor deviations when it can still interpret the intended meaning. That posture was especially useful when the Internet needed to connect heterogeneous systems built by different organizations.

The principle should not be read as an instruction to ignore errors. It is a rule about where to place tolerance in order to preserve communication.

Why conservative sending matters

Conservative sending remains the least controversial half of the law. When a system emits well-formed, standards-compliant output, it reduces the burden on every consumer. Strict output makes behavior easier to test, document, integrate, secure and evolve. It also prevents a sender's local shortcut from becoming somebody else's parsing problem.

This is why the principle begins with discipline at the source. A system that sends ambiguous, malformed, or loosely interpreted data shifts complexity downstream. Each receiver must then guess what the sender meant and those guesses can diverge. The result is fragmentation rather than interoperability.

Early TCP guidance captured this asymmetry directly: implementations should conform carefully when sending, while receivers should tolerate faults only where interpretation remains possible2. Conservative sending is therefore a form of ecosystem stewardship.

Why liberal acceptance helped

Liberal acceptance helped early networked systems communicate across imperfect implementations. Protocols were new, implementations differed and operational conditions were unpredictable. Rejecting every deviation would have made interoperability brittle. A receiver that could safely interpret an imperfect message often created more value by continuing than by failing hard.

The original principle was therefore pragmatic. It recognized that real networks produce malformed packets, partial conformance and unexpected combinations of attributes. A receiver prepared for those conditions could prevent local defects from becoming global outages.

That benefit still exists in carefully bounded situations. A user-facing importer may reasonably normalize harmless whitespace. A parser may accept an optional field ordering if the schema makes meaning unambiguous. The key qualifier is safe interpretation. Tolerance is valuable only when it does not conceal a material defect or create an unclear contract.

Where tolerance becomes harmful

The difficulty with Postel's Law is that liberal acceptance can remove the feedback that would correct bad behavior. If a receiver silently accepts malformed input, the sender may never discover the problem. The malformed behavior then persists, spreads and eventually becomes something other implementations must also support.

The Internet Engineering Task Force [IETF] has documented this long-term risk. Its work on the harmful consequences of the Robustness Principle argues that liberal acceptance can promote interoperability in the short term but can also create negative effects in the protocol ecosystem over time3. Tolerance can convert accidental behavior into a de facto standard.

This is not a theoretical concern. Once users or systems rely on permissive behavior, maintainers may be forced into bug-for-bug compatibility. What began as a workaround becomes an obligation.

Security and ambiguity

Security raises the cost of tolerant parsing. When different components interpret the same malformed input differently, attackers can exploit the gap. A gateway may accept a message one way, while a backend interprets it another way. The result can be request smuggling, validation bypass, inconsistent authorization, or data corruption.

The lesson is that input tolerance must be contextual. Accepting a harmless formatting variation in a low-risk display format is not the same as accepting ambiguous syntax at a security boundary. Modern parser-security work argues for clearly defining the boundary between acceptable variation and rejection, rather than treating every recoverable input as valid4.

Robustness does not mean accepting everything. In high-assurance systems, predictable rejection can be safer and more interoperable than silent recovery.

Applying the law to APIs

Application programming interfaces [APIs] make the trade-offs visible. An API provider should send stable schemas, explicit types, documented defaults and valid error responses. That is conservative sending. It makes the provider easier to integrate with and reduces downstream defensive code.

On input, the provider should decide deliberately which variations it accepts. It may normalize a trailing space, support a legacy field during migration, or tolerate an optional order. But each exception should have an owner, telemetry, a security assessment and a retirement plan. Undocumented tolerance without visibility is simply unmeasured compatibility debt.

Modern API guidance often frames the practical approach this way: validate inputs, be explicit about what is accepted and returned and avoid changes that cause regressions for existing consumers5. The aim is not maximal permissiveness. It is dependable interoperability.

A modern operating model

Teams should separate transitional tolerance from permanent contract. Transitional tolerance supports migration from known legacy behavior to a clearer target. Permanent contract defines the behavior that consumers can rely on over time. Conflating the two causes systems to accumulate accidental commitments.

A useful operating model has four parts:

1. Send strictly conformant output at every external boundary
2. Define accepted input variation explicitly and reject ambiguity that cannot be interpreted safely
3. Instrument tolerated deviations so teams know who still depends on them
4. Communicate and enforce migration deadlines before a temporary compatibility path becomes permanent

This approach preserves the original goal of interoperability while addressing its modern failure modes. It recognizes that robustness depends on feedback loops, not merely on graceful recovery.

The strategic lesson

Postel's Law is best understood as a trade-off rule, not a commandment. Conservative sending creates clarity. Liberal acceptance creates resilience only when bounded by safety, visibility and a path back to conformance. At scale, indiscriminate tolerance does not create robust ecosystems. It creates opaque ones.

Leaders should therefore ask whether an acceptance rule is helping a user recover from a benign variation or allowing a defect to become entrenched. The answer determines whether the rule produces interoperability or technical debt. The strongest systems remain strict about what they emit and selective about what they forgive.

• 1Requirements for Internet Hosts -- Communication Layers
• 2Postel's Law
• 3The Harmful Consequences of the Robustness Principle
• 4A Patch for Postel's Robustness Principle
• 5Postel's law for API robustness