Postel's Law

Be conservative in what you send and liberal in what you accept.

“In general, an implementation should be conservative in its sending behavior, and liberal in its receiving behavior.”
— Jon Postel (ed.), RFC 760, DoD Standard Internet Protocol (1980)

Senders stick strictly to the contract while readers tolerate what they do not recognise, so each side can evolve on its own.

To an executive

Systems that tolerate small differences from partners keep working without constant coordinated upgrades. Too much tolerance, though, can let poor practice spread and become costly to unpick.

To an engineer

Send strictly to the published contract and read tolerantly, ignoring fields you don't recognise. Be wary of accepting malformed input, because tolerated quirks can harden into requirements.

The idea

Jon Postel wrote the robustness principle into the TCP specification, RFC 761, in 1980: TCP implementations should be conservative in what they do and liberal in what they accept from others. RFC 1122 later restated it for all layers as "be liberal in what you accept, and conservative in what you send". It helped many independent implementations work together on the early Internet.

For architects, the modern form is the tolerant reader: producers stick tightly to the published contract, and consumers ignore what they do not recognise. Each side can then evolve without the other's release.

The principle has critics. RFC 9413, published by the Internet Architecture Board in 2023, argues that some readings of it harm interoperability over time. Liberal acceptance lets sloppy senders persist, and tolerated quirks become requirements every other implementation must copy.

Why it works

Tolerant readers allow additive change. If consumers ignore unknown fields, producers can add fields without a coordinated release.

Strict senders keep the contract clean. If producers send only what the contract defines, consumers have less to guess about.

Independence reduces coordination. Teams that do not need to release together move faster and break each other less.

Where it applies

Event and message schemas, where many consumers read what one producer writes.
Public and partner APIs, where you cannot upgrade all clients at once.
Data integration and file formats, where inputs come from many sources of varying quality.

How to apply

Make consumers tolerant of additions. Ignore unknown fields and use defaults for missing optional ones.
Make producers strict. Validate outgoing messages against the published schema before sending.
Be strict at trust boundaries. Reject malformed or ambiguous input from untrusted sources, and log what you reject.
Maintain the contract actively. When you see a common deviation, fix the sender or update the specification, rather than tolerating it silently forever.

Example scenario

An order service crashed whenever an upstream team added a field to its order-placed event, because its deserialiser rejected unknown properties. Every schema change needed a coordinated release of both services, and the upstream team had started batching changes to avoid the pain.

The order service switched to tolerant deserialisation that ignored unknown fields, and the upstream team added schema validation to its publishing pipeline. Producers could now add fields freely, and consumers picked them up when they were ready. Payment details, which crossed a trust boundary, kept strict validation.

Questions to ask

Will our consumers break if a producer adds a field they don't recognise?
Where do we sit on a trust boundary, and are we strict there?
Are we accepting malformed input that will quietly become part of the contract?

When not to use it

Security-relevant input, such as authentication tokens or anything parsed from untrusted users, where leniency opens doors.
Protocols you actively maintain with a small set of implementations, where fixing the sender is cheaper than tolerating it.

How it misleads you

Applying liberal acceptance to untrusted input opens the door to injection and parsing exploits. Being liberal for years also turns quirks into a hidden contract, which Hyrum's Law then makes impossible to remove. Tolerate additive change; be strict about everything else.

In the wild

IAB's RFC 9413, 'Maintaining Robust Protocols', 2023The Internet Architecture Board's RFC argues that tolerating faulty input lets implementation quirks become de facto standards that others must copy, hides bugs and weakens security, and recommends active protocol maintenance over unlimited leniency.Internet Engineering Task Force (IAB, RFC 9413) · 2023 (opens in a new tab)