What is Postel's law?
Engineering culture and software practice
Postel's law, also called the robustness principle, says be conservative in what you send and liberal in what you accept. Jon Postel wrote it into the early internet protocol specifications around 1980. It explains why so much of the internet interoperates despite sloppy implementations, and it is also why many security engineers now argue the principle has aged badly and needs tighter application at security boundaries.
What this means
Postel's law is a design stance about how systems should treat the data they send and receive. Be strict about what you emit: follow the specification exactly, so others can rely on you. Be tolerant about what you take in: if a message is slightly malformed but its meaning is clear, accept it rather than rejecting it. The aim is to let independently built systems work together even when neither is perfect.
For decades this was accepted wisdom, and it worked. It is a large part of why the early internet grew so fast: implementations that forgave each other's small mistakes could still talk. Web browsers, famously, went to great lengths to render broken web pages rather than refuse them.
The principle has a name partly because it is now contested. The same tolerance that helped things interoperate turns out to create long-term problems, especially around security, and the modern guidance is more careful about where being liberal is safe and where it is dangerous.
Why it matters
Any organisation that connects systems together lives with Postel's law whether it knows the name or not. Every integration, API, data feed and spreadsheet import faces the choice between strict and tolerant handling of input, and that choice has real consequences for reliability and safety.
The comfortable side is familiar: a partner sends a slightly wrong file and your system loads it anyway, so nobody has to stop and fix the format. That tolerance keeps things moving. The uncomfortable side is that the same tolerance quietly accepts and normalises errors, so nobody ever fixes the partner's broken export, divergent behaviours pile up, and a malformed input that "just works" can also be the crack an attacker uses. What looks like helpfulness can be an accumulating liability.
It matters acutely for anything exposed to untrusted or hostile input, including AI systems fed text from the outside world, where over-liberal acceptance of instructions is the root of prompt injection. For a leader signing off an integration, understanding the principle turns a vague sense that "it works" into pointed questions about where the system should forgive and where it must refuse.
How it works
Where the term came from
Jon Postel was the editor of many of the foundational internet standards. The principle appears in RFC 761, the Transmission Control Protocol specification of January 1980, whose section 2.10, headed "Robustness Principle", states that TCP implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others. It was restated as a general requirement for internet hosts in RFC 1122 in 1989, which phrases it as being liberal in what you accept and conservative in what you send, and stresses that it matters at every layer. Because Postel wrote it down, the maxim became known as Postel's law.
The modern reconsideration is well documented. Eric Allman, a co-founder of Sendmail, published "The Robustness Principle Reconsidered" in ACM Queue in 2011, arguing that the principle failed more when ignored in its early years but had since been challenged because the world had become more hostile, raising problems for both interoperability and security. The Internet Engineering Task Force went further in RFC 9413, "Maintaining Robust Protocols" (2023), which warns that reacting to variation the way the robustness principle recommends can create a pathological feedback cycle, where tolerated errors become entrenched as de facto standards that every implementation must then replicate.
How tolerance shaped the web
The clearest example of liberal acceptance is the web browser. Early browsers competed partly on how gracefully they coped with broken HTML, guessing at what an author meant and rendering something reasonable. This made the web welcoming to amateurs and helped it explode in size. But it also meant no two browsers coped identically, so authors wrote pages that worked in one and broke in another, and years of effort went into standardising the error handling itself so that "liberal" behaviour became predictable rather than a free-for-all.
The security turn: why liberal acceptance became dangerous
The critique is not that engineers got worse; it is that the environment changed. When inputs may be hostile, being generous with malformed data becomes an attack surface. Two systems that parse the same input slightly differently create a parsing differential, a gap an attacker can exploit to smuggle something past one check that another will act on. Tolerantly accepting unexpected content is also how injection attacks work. The very forgiveness that aided interoperability now aids intrusion, which is why the guidance has shifted.
How experienced teams apply it now
The current stance is not to abandon tolerance but to place it carefully. At security boundaries, parse strictly and fail closed: reject anything that does not conform, rather than guessing. Version interfaces explicitly so that change is negotiated rather than smuggled through liberal acceptance. Keep tolerance for places where humans type and small mistakes are normal, such as a date typed without a time zone or a form field with stray spaces. And, as RFC 9413 urges, maintain protocols actively so ambiguities are resolved over time instead of being papered over by ever more forgiving parsers.
Examples
A retailer receives a daily stock file from a supplier whose export is slightly malformed, with an extra column and inconsistent date formats. The import system is liberal and loads it anyway, which feels like a win until the day the supplier's format drifts a little further and the system silently misreads prices. Because the tolerance masked the underlying problem for months, nobody had ever asked the supplier to fix the export, and the error only surfaced when customers were overcharged.
A council department exposes an API for partner agencies to submit case referrals. Following the security turn in the guidance, the team parses submissions strictly and fails closed, rejecting anything that does not match the agreed format with a clear error, and versions the interface so changes are announced rather than improvised. Referrals are marginally less convenient to submit, but malformed or malicious payloads are turned away at the door rather than half-processed.
A professional services firm connects an AI assistant to an inbox so it can summarise incoming messages. Because the assistant is liberal in accepting whatever text arrives, a message containing hidden instructions manages to steer it, a classic prompt injection. The firm learns that untrusted input is exactly the place where liberal acceptance is dangerous, and adds strict handling and guardrails around what the assistant is allowed to act on.
Common misunderstandings
A common misunderstanding is that Postel's law means you should accept anything at all. It never meant that. Even the original wording was about accepting non-conformant input whose meaning is clear, not about processing meaningless or malicious data. Tolerance was always meant to have limits.
Another is that the principle has been proven wrong and should be discarded. The more accurate picture is that its scope has narrowed: still valuable where inputs are friendly and humans are involved, but dangerous at security boundaries. It is being refined, not abolished.
A third confusion is with Hyrum's law. Postel's law is a design stance about how you treat input you receive, whereas Hyrum's law is an observation that once an interface has users, every observable behaviour of it, including accidents, will come to be depended upon by someone. Rather than being two versions of one idea, Postel is about your generosity as a receiver and Hyrum is about what consumers do with everything you expose. Draw that line clearly.
A fourth error is thinking strictness and robustness are opposites. Modern practice treats disciplined strictness, especially failing closed at boundaries, as a route to robustness, because it stops errors becoming entrenched.
A fifth is assuming the principle only concerns network protocols. It applies to any input handling, from file imports and form fields to the text fed to an AI system.
Risks and boundaries
The principle is misapplied whenever liberal acceptance is used as a substitute for fixing the real problem. Silently coping with a partner's broken output feels efficient but lets faults accumulate and hides them until they cause damage, and RFC 9413 describes exactly how tolerated errors can harden into de facto standards that everyone is then forced to support.
There is a genuine debate about balance. Allman argued for moderation rather than rejection of the principle, and RFC 9413 offers active maintenance as the alternative to endless tolerance. The honest summary is that liberal acceptance is still right in some places and wrong in others, and the skill is telling them apart rather than adopting a single rule everywhere.
The boundary for a leader is that tolerance is a considered choice, not a default. Where inputs may be untrusted or where errors carry real cost, the safer stance is strict parsing and clear rejection, with tolerance reserved for low-stakes, human-facing input.
What to do next
When signing off an integration, ask where the system is tolerant and where it is strict, and make sure that split is deliberate. Tolerance is fine for human-entered fields; strictness should be the rule where data crosses a trust boundary or feeds a decision with real consequences.
Ask what happens when input is wrong. A system that silently accepts and guesses is storing up trouble; one that fails closed with a clear error protects you, even if it is slightly less convenient for the sender. Prefer the latter at any security or money-touching boundary.
Insist on explicit versioning for interfaces with partners and suppliers, so that format changes are negotiated and announced rather than absorbed by ever more forgiving parsing.
Do not let tolerance excuse a broken source. If a partner's file is consistently malformed, get it fixed rather than coding around it forever, because the workaround hides the fault until it fails expensively.
For AI systems that consume untrusted text, treat liberal acceptance as a risk. Add strict handling and guardrails around what the system may act on, and read the prompt-injection guidance before connecting an assistant to external input.
FAQs
What exactly does Postel's law say?
Be conservative in what you send and liberal in what you accept. In the original TCP wording, be conservative in what you do and liberal in what you accept from others.
Where does it come from?
Jon Postel wrote it into the TCP specification, RFC 761, in January 1980, and it was restated as a general host requirement in RFC 1122 in 1989. It is named after him.
Why is it credited with the internet's success?
Because implementations that forgave each other's small mistakes could still interoperate, which let the early internet and the web grow quickly despite imperfect, independently built systems.
Why do security engineers criticise it now?
Liberal acceptance of malformed input creates attack surface. Systems that parse the same data differently create exploitable gaps, and tolerant handling is how many injection attacks succeed. The environment became hostile.
Has the principle been abandoned?
No, its scope has narrowed. Guidance such as ACM Queue in 2011 and RFC 9413 in 2023 recommends strict parsing and failing closed at security boundaries, keeping tolerance mainly for human-facing input.
How is Postel's law different from Hyrum's law?
Postel is a design stance about how liberally you accept input. Hyrum's law observes that consumers will end up depending on every observable behaviour of your interface. One is about receiving, the other about what others rely on.
How does it relate to AI and prompt injection?
An AI system that liberally accepts untrusted text can be steered by hidden instructions in that text, which is prompt injection. It is a prime example of where liberal acceptance is dangerous and needs strict guardrails.