Postel's Law

011 min

Postel's Law at a glance

• What it is: strict about what you send, tolerant of variation in what you accept.
• Origin: Jon Postel, RFC 761, 1980; restated for every host in RFC 1122, 1989.
• What it costs: tolerated errors go undetected until a stricter implementation meets them.
• When it doesn't apply: protocols needing exact agreement, like XML, reject tolerance outright.

021 min

The problem Postel's Law responds to

Early ARPANET and Internet software was written independently by different research teams and vendors, all implementing the same young, sometimes ambiguous specifications. Small differences crept in: a header field in an unusual order, an option nobody else used, a whitespace convention one team read differently from another. If every implementation demanded byte-for-byte conformance to the specification, two computers running slightly different, equally sincere readings of the same document could not talk to each other. That would hold even when both messages meant exactly the same thing.

A single overly strict implementation could refuse a connection over a detail that changed nothing about the data being sent. RFC 1122 states the stakes plainly: one misbehaving host can deny Internet service to many other hosts. A network built by hundreds of independent teams is only as reachable as its least tolerant participant. Postel's Law exists to stop one overstrict implementation from cutting itself, and everyone who depends on it, off from a network nobody fully controls.

032 min

How Postel's Law actually works

Postel's Law splits a protocol implementation into two jobs and gives each one a different standard. On the sending side: be conservative. Every message your software emits should follow the specification exactly, with no undocumented shortcuts and no formatting a reader could interpret two ways.

On the receiving side: be liberal. Accept variations whose meaning survives them:

• an extra field the specification never defined
• a key or field appearing in an unusual but unambiguous order
• a harmless default standing in for a missing value

Reject only the input where the meaning is genuinely unclear, not input that merely looks unfamiliar.

Postel wrote the rule for one specific protocol first. RFC 761, the 1980 specification for TCP, states it directly in a section titled Robustness Principle. Its wording is exact: be conservative in what you do, be liberal in what you accept from others. Nine years later, RFC 1122 lifted the identical instruction out of TCP and applied it to every protocol layer a host runs, because a stack is only as tolerant as its strictest layer.

The asymmetry is the entire mechanism. A sender that is loose about its own output has no way to know which of its shortcuts a given receiver will accept, so looseness on the sending side multiplies the number of interpretations every receiver has to handle. A receiver that is strict about accepting input rejects a sender's honest, slightly non-standard message over a detail that changed nothing about what was meant. Putting the strict half on the side you control, and the lenient half on the side you do not, is what lets independently written implementations interoperate without a central authority forcing every team onto identical code.

RFC 1122 is explicit that liberal does not mean naive. It directs implementers to assume the network is filled with malevolent entities that will send in packets designed to have the worst possible effect, and to design for that threat, not just for honest variation. Software built this way is what engineers call robust: not immune to bad input, but built to keep working when it arrives.

041 min

Where the term Postel's Law comes from

Jon Postel edited RFC 761, the Transmission Control Protocol specification published in January 1980, and gave the robustness principle its own numbered section rather than folding it into general prose. The wording is actually a year older than that. Wikipedia's history of the principle records that it was first written down by Jon Postel in the 1979 IPv4 specification, a year before he restated it for TCP.

Postel was well placed to make an idea like this spread everywhere. He was the RFC Editor from 1969 until his death, shepherding nearly every foundational Internet specification through the same series. He died on October 16, 1998, of complications from heart surgery.

The name most people use today is a later, informal label: Postel's Law. The RFC series itself only ever calls it the Robustness Principle. Bob Braden made the rule binding well beyond TCP in October 1989, restating it inside RFC 1122, the document that sets the baseline requirements for every Internet host, so every protocol layer a computer runs inherited the same conservative-sender, liberal-receiver split.

052 min

Postel's Law in web browsers

Every web browser ever shipped applies Postel's Law to HTML, at a scale no other example matches. Billions of pages, most of them with at least one syntax error, are all expected to render the same way in every browser. The WHATWG HTML Living Standard is explicit that this is the goal, not an accident. It defines the parsing rules for HTML documents whether they are syntactically correct or not. Rejecting a page over stray markup was never realistic for a web read mostly by people who cannot see the raw file.

What makes this the clean example is not that the spec tolerates errors, but exactly how it does it. Early browsers each guessed what to do with a missing closing tag or a b element left open across paragraphs, and different guesses meant the same broken page rendered differently in each browser. The HTML5 parsing algorithm ended that by specifying precisely what every conforming implementation must do with each class of malformed markup, tag by tag, insertion mode by insertion mode. So liberal in what you accept stopped meaning whatever this parser happens to do, and started meaning one documented flexibility every browser implements the same way.

A page author sending sloppy markup is still tolerated. The receiver's leniency is no longer a guess. That distinction, precise and specified tolerance rather than vague and implementation-specific tolerance, is exactly the fix later critics of Postel's Law say the principle needed from the start.

061 min

What Postel's Law costs, even done right

Even a textbook-correct implementation of Postel's Law pays a real cost: every accepted variation is one more thing every future maintainer has to keep supporting. A receiver that quietly tolerates a malformed field cannot later start rejecting it without breaking every sender that has come to depend on the tolerance, even senders who were technically wrong all along. RFC 9413, the IETF's own 2023 reassessment of the principle, states plainly that tolerating unexpected input relies on an assumption that existing specifications and implementations cannot change. That assumption gets less true, not more, the longer a protocol stays popular.

The cost compounds because tolerance is invisible until it is tested. Nobody sees the malformed messages a receiver quietly accepted and corrected. They see only the message that finally, unpredictably, triggers a code path nobody has exercised or reviewed since the implementation shipped. That code path is where security bugs live, because handling unexpected input safely is a strictly harder job than handling only the input the specification defined. RFC 9413 makes the connection explicit: hiding the consequences of protocol variations encourages the hiding of issues, which can conceal bugs and make them difficult to discover. The team that eventually pays for a decade of quiet tolerance is rarely the team that wrote it.

071 min

When Postel's Law is the wrong tool

Postel's Law is the wrong tool wherever a protocol's whole purpose is that every implementation reads a document identically, with no implementation-specific guessing at all. XML is the clearest deliberate rejection: its own specification states that violations of well-formedness constraints are fatal errors, so a processor that quietly tolerated a malformed tag would itself be non-conformant. The choice was not an oversight. XML documents are consumed by systems that make decisions from the data, not by a person who can eyeball a rendered page and spot what went wrong, so a silently corrected document is more dangerous than one that visibly fails.

The same failure mode shows up as a security hole, not just an interoperability one. A 2018 study by Florentin Rochet and Olivier Pereira found a security cost for that same choice, inside Tor rather than XML. The Tor protocol requires nodes to ignore messages that are not understood, in order to guarantee compatibility with future protocol versions. Rochet and Pereira used that tolerance itself as a side channel. Watching which messages the network silently dropped let them identify the entry relay protecting a hidden service in about a day, without injecting a single relay into the network.

Both failures share a root cause: tolerance that never classifies what it is tolerating by error severity cannot tell a harmless variation from a dangerous one.

082 min

Where the evidence on Postel's Law is contested

The criticism is not new, and it is not from outsiders. Marshall Rose raised the same argument inside the IETF two decades earlier, in RFC 3117, published in November 2001. He wrote that, counter-intuitively, Postel's robustness principle often leads to deployment problems. A new, slightly non-conforming implementation first meets only tolerant partners, so its errors go undetected and it spreads. Eventually it meets a less tolerant partner, and the accumulated incompatibility surfaces all at once, far from the bug that caused it. Rose's own fix was blunt. He recommended explicit consistency checks in a protocol, even if they impose implementation overhead.

The IETF's own Internet Architecture Board revisited the argument formally twenty-two years later. RFC 9413, published in June 2023 and authored by Martin Thomson and David Schinazi, states that an implementation that reacts to variations in the manner recommended in the robustness principle enters a pathological feedback cycle. Each tolerated deviation becomes normal, and newer implementations then have a strong incentive to tolerate any existing non-compliance in order to be successfully deployed. The document's central example is BGP, the protocol that routes traffic between every network on the Internet. RFC 4271 mandated a session reset for invalid UPDATE messages, a requirement that was not widely implemented. Real routers quietly tolerated malformed updates in inconsistent ways for years, until RFC 7606 documented what deployed routers actually did and turned it into the rule.

091 min

Postel's Law vs. Poka-Yoke

The nearest neighbor is not another law about networks. It is poka-yoke, the manufacturing discipline of designing a process so a mistake cannot physically happen in the first place. The two sit on opposite sides of the same problem. Postel's Law assumes bad input will arrive and asks the receiver to absorb it gracefully. Poka-Yoke assumes the same thing and asks the sender's process to make the bad input impossible to produce at all: a connector shaped so it only fits one way, a form field that rejects a malformed value before it is ever submitted.

A system that only forgives errors after the fact, with no upstream poka-yoke at all, is the shape RFC 9413 criticizes: tolerance with nothing pushing the error rate down over time. The two work best paired, not chosen between. Poka-yoke narrows how much variation a receiver ever has to tolerate, and Postel's Law covers whatever slips through anyway.

102 min

How Postel's Law shows up in product and engineering work

Outside of network protocols, the clearest modern version of this decision is a public API's request and response schema. It is a decision a product manager and an engineer make together, not one the engineer makes alone.

A PM defining what a public API accepts is making the sending-versus-receiving call every time a field gets added to a request payload. Should the API reject any request containing a field it does not recognize, or should it silently ignore unknown fields and process the rest? Rejecting outright is the strict, XML-flavored choice. It catches a caller's typo immediately, but it breaks every existing integration the moment the schema adds a new optional field, because an older caller's request now looks like it forgot something it never had to send. Ignoring unknown fields is the Postel's Law choice: existing integrations keep working across schema changes, at the cost of never telling a caller their request had a field with a misspelled name that silently did nothing.

An engineer meets the same decision from the other direction, writing the parser that reads an upstream response. A response parser that throws on any unrecognized field turns a vendor's harmless schema addition into an outage the next time that vendor ships one, at a moment the engineer's own team does not control and cannot predict. A parser written to read only the fields it needs, and ignore the rest, survives that same change without a deploy. The trade-off is not free either way. A parser that ignores too much can also miss a field whose absence should have been a loud error rather than a quiet default, which is exactly the failure mode Postel's Law's critics describe. The decision belongs in the API contract itself, documented once, rather than left to whichever behavior each client's parser happened to implement.

111 min

Applying Postel's Law

Applying Postel's Law well starts with separating the two halves instead of treating tolerance as the whole rule. Write the part your own software sends as strictly as the specification allows, with no undocumented shortcuts. Every shortcut you ship becomes something every future consumer of your output has to handle, whether they know about it or not.

Write the part that reads other people's input to tolerate variation only where the meaning genuinely survives it: an extra field, a different key ordering, a harmless default. Reject, loudly and specifically, anything where the meaning is actually ambiguous.

The fix worth borrowing from Postel's Law's own critics is to make the tolerance visible instead of silent. In practice that means two things: logging every tolerated deviation instead of silently absorbing it, and setting a real deprecation date for old, non-conforming behavior instead of assuming today's leniency is permanent. Tolerance that nobody tracks does not stay safe. It accumulates until removing it would break something that now depends on it staying wrong. Logged and deprecated on a schedule, that tolerance becomes a genuine fail-safe. Left untracked, it is only an unexamined assumption.

122 min

Frequently asked questions about Postel's Law

?7 questions

Questions people ask

§11 sources

Sources