Postel's Law
Learn it → Apply it → Save as Skill
Be strict in what you send, and forgiving in what you accept — but only for a while. Tolerating small imperfections from others keeps systems working together today. Left unmanaged forever, that same tolerance quietly turns someone else's mistake into a permanent requirement for everybody downstream.
Learn it. Apply it. Save as Skill.
The Dr. Wallace’s Favorite Mental Models is designed to turn useful ways of thinking into reusable tools. Each model gives you a fast visual overview, deeper interactive learning, practical application exercises and an AI-ready Markdown skill you can save for future use.
Instead of merely reading about mental models, you can gradually build your own AI skills library: a collection of portable reasoning skills that can help ChatGPT, Claude, Grok and other AI assistants apply the mental models you value.
When two systems built by different people have to talk to each other, neither will match the spec perfectly. If you demand perfection from what you receive, small honest mistakes break everything. If you also send sloppy data yourself, ambiguity multiplies. The fix: hold yourself to the letter of the spec, and give others a little room — on purpose, and only for a while.
The same leniency, two very different timelines
Tolerance is cheap on day one and compounds like debt. A workaround nobody tracks becomes, a few years later, something thousands of clients secretly depend on — documented in real protocol work as implementations becoming "bug-for-bug compatible" with each other's accepted flaws. A workaround that is tracked and sunset on a schedule never reaches that point.
Use it before you decide how strict your system should be.
The model is most useful right before you write an input-validation policy, design an API contract, integrate with a partner system, or decide how an AI agent should handle imperfect tool-call arguments.
Specify → Send strictly → Accept carefully → Maintain.
Postel's Law is often remembered as one soft rule. Applied well, it's a four-part discipline with an expiration date built in.
Write down exactly what your system sends and exactly what it is willing to accept, including the edge cases, so "liberal" has a defined boundary instead of meaning "anything."
Whatever you send to others should conform exactly to the agreed spec. Never rely on the other side's leniency to cover for your own sloppiness.
Tolerate small, well-understood deviations from others — but log them, measure how often they occur, and never silently stay quiet about a deviation that could hide a real error or a security issue.
Revisit every tolerated quirk on a schedule. An uncorrected deviation left alone long enough stops being a workaround and becomes a requirement everyone downstream now depends on.
Six things worth understanding before you apply it.
Expand each to see the exact wording, why it was written, and the well-documented ways it goes wrong when left unmanaged.
The Law
The exact statement
The common phrasing is "be conservative in what you do, be liberal in what you accept from others." Jon Postel first wrote the idea into the 1979 IPv4 specification (IEN 111), and restated it in January 1980 in the Internet Protocol and Transmission Control Protocol specifications he edited (RFC 760 and RFC 761) — the documents that defined the basic protocols the internet still runs on.
Why it was written
A young network, many independent implementers
In the ARPANET era, different teams wrote their own implementations of the same spec, and real implementations rarely matched the spec exactly. If every node rejected any message that wasn't letter-perfect, the still-young network would have failed constantly over trivial mismatches. Tolerating small, known deviations kept the network usable while the inevitable bugs got found and fixed.
The hidden cost
Tolerance becomes a dependency
Engineer Marshall Rose observed in 2001 that a sender with a small defect, tolerated by lenient receivers, can run for years without anyone noticing. By the time a stricter receiver finally rejects it, an enormous amount of deployed software has come to depend on the original defect — now a de facto requirement, expensive and disruptive to fix.
The modern correction
"The robustness principle reconsidered"
In a 2017 Internet-Draft, "The Harmful Consequences of the Robustness Principle," Martin Thomson argued that permanently tolerated deviations accumulate into implementations being bug-for-bug compatible with each other's mistakes, which raises the cost of building new, correct implementations and can entrench protocol forks. That line of work led to the IETF's RFC 9413, "Maintaining Robust Protocols," which recommends active, ongoing protocol maintenance over indefinite silent tolerance.
The security angle
Leniency can be exploited, not just accumulated
Researchers Rochet and Pereira showed in 2018 that the liberal-acceptance side of the principle could itself be turned into an attack: in Tor's onion-routing protocol, tolerant handling of certain inputs could be exploited to weaken anonymity guarantees for clients and services. Leniency is not automatically a neutral, low-risk default.
Where it still clearly works
Young systems, short-lived interactions, low stakes
The principle still earns its keep in early-stage protocols without mature strict-validation tooling, short-lived or low-stakes interactions, and small, trusted integrations where an occasional rejected input costs more than quietly absorbing minor formatting drift. The failure mode shows up specifically in long-lived, high-stakes, widely-implemented systems where nobody ever revisits what's being tolerated.
A public API has been quietly tolerant for three years.
This is an illustrative example designed to teach the method.
The same send-strict, accept-carefully pattern shows up well outside networking.
Postel wrote about internet protocols, but the underlying trade-off applies anywhere two independently-built systems, or people, have to cooperate.
Repairing broken HTML
Browsers accept malformed HTML — unclosed tags, bad nesting — and silently repair it, which is why broken pages rarely crash. It is also why browser makers still maintain decades-old, exactly-specified repair algorithms: the repaired behavior itself became the spec.
Deliverability over purity
Mail servers commonly accept slightly malformed headers from legacy systems to protect deliverability, while authoring their own outgoing messages to the letter of the spec — the two halves of the law, applied asymmetrically on purpose.
Parsing imperfect model output
An AI agent that receives slightly malformed arguments from a model — a trailing comma, an unquoted key — can parse leniently to keep the interaction working, but should log the deviation and still validate the result against the real schema, rather than quietly accepting anything that merely looks close enough.
Flexible input, canonical storage
A sign-up form that accepts phone numbers typed in many formats client-side, then always sends one strict, canonical format to the backend, gets the user-facing flexibility without pushing the ambiguity any further downstream than it has to go.
Conservative sender, or liberal receiver?
Each scenario below is a design choice. Pick which half of the principle it demonstrates, then check yourself.
1. A payment service always sends dates in one exact ISO-8601 format, even though its own documentation lists three "acceptable" formats for incoming data.
2. A checkout form accepts a credit card number whether or not the customer types spaces or dashes in it.
3. An internal microservice refuses to emit a field that is merely "probably fine" — it only ever sends fields that fully match the published schema.
4. An email client still renders a message correctly even though the sending server left out an optional header most modern systems include.
A 1979 line in a spec that became one of networking's most quoted, and most contested, rules.
Expand for the origin of the model, where it stands today, and how it differs from a related, newer law.
Where did Postel's Law come from?
Jon Postel (1943–1998) earned a B.S. (1966), M.S. (1968) and Ph.D. in computer science (1974) from UCLA. He edited the Internet's Request for Comments series from 1969 until his death, wrote or co-authored more than 200 RFCs including the core specifications for IP and TCP, and directed the Internet Assigned Numbers Authority (IANA) from its inception. He first wrote the robustness principle into the 1979 IPv4 specification and restated it in the January 1980 IP and TCP specifications. He was sometimes called the "god of the Internet" for his influence, a title he rejected, saying the Internet works because many people cooperate.
Is it still considered good advice today?
It's more contested than it once was. It's still cited approvingly for young or evolving systems and for graceful degradation in low-stakes interactions. But a body of IETF work from 2017 onward — culminating in RFC 9413, "Maintaining Robust Protocols" — argues that permanent, unmaintained tolerance degrades long-lived protocols over time. Most serious treatments today present Postel's Law alongside its documented failure mode rather than as unconditional advice.
Is this the same thing as Hyrum's Law?
No, though they compound each other. Postel's Law is a design recommendation about how to handle input before problems happen: send strictly, accept carefully. Hyrum's Law describes what happens after tolerant behavior ships — with enough users, every observable behavior of a system, intended or not, ends up depended on by somebody. Practicing Postel's Law without the "maintain" step is exactly how a system backs into the situation Hyrum's Law describes.
The phrase is simple; applying it responsibly is not.
Reading "liberal" as "forever"
Treating tolerance as a permanent policy rather than a deliberate, temporary bridge with a review date.
Being liberal on both ends
Accepting loosely and sending loosely at the same time multiplies ambiguity instead of containing it on one side.
Never auditing what's actually tolerated
Without logging and measuring which quirks real traffic depends on, nobody notices when a workaround becomes load-bearing.
Treating leniency as security-neutral
Tolerant handling can conceal bugs or be directly exploited, as shown in real protocol security research — it is a trade-off, not a free lunch.
Applying young-protocol thinking to a mature one
What kept an early-stage network usable can quietly erode a widely-implemented, long-lived protocol that nobody is actively maintaining.
Forgetting the "conservative" half
Only ever practicing the liberal-acceptance half while never holding your own outgoing data to the spec.
Some situations need a different default.
Use strict validation when...
the system is security-sensitive, or ambiguous input could hide an attack, corrupt data, or produce a silently wrong result instead of a clear error.
Use a versioned deprecation plan when...
a tolerated quirk has already been identified — leniency should have a sunset date and a migration path, not run indefinitely by default.
Use active protocol maintenance when...
you control both ends of a long-lived, evolving system — ongoing feedback and enforcement beats permanent, unmanaged tolerance, per RFC 9413's "maintain the protocol" approach.
One model rarely does the whole job.
Build a Postel's Law review prompt.
This browser tool structures your thinking. It does not send your information anywhere or perform AI analysis.
Your AI-ready prompt
Turn this mental model into a reusable AI skill.
Save as Skill converts the model into portable Markdown instructions that teach an AI when and how to apply Postel's Law, what questions to ask, what evidence to seek, what mistakes to avoid and how to structure its analysis.
Build your own Mental Models Skills Library
Save the skills you find useful and organize them into your own reusable library. The Markdown is intentionally model-neutral, so it can be used wherever an AI system accepts uploaded files, project knowledge, custom instructions or reusable text context. Platform capabilities differ, so this is a portable skill file rather than a claim of one-click installation.
For readers who want the nuance.
Does Postel's Law mean I should never reject bad input?
No. It means any tolerance should be a deliberate, scoped, reviewed decision rather than a default you never revisit. Rejecting bad input with a clear error is often the right call, especially where ambiguity could hide a security issue or corrupt data.
Why do modern protocol designers sometimes say "Postel was wrong"?
They're not rejecting the underlying trade-off — they're rejecting treating it as permanent, unmanaged policy. The critique, formalized in RFC 9413, is that tolerated deviations left unmaintained accumulate into "bug-for-bug compatible" implementations that are expensive to fix and can hide real bugs, including security-relevant ones.
Is there a domain where this stops being useful advice?
Its clearest fit is interoperability between independently built systems — networking, APIs, file formats, AI tool-calling. It gets less useful once a system is mature, security-sensitive, and widely implemented without anyone actively maintaining which quirks are tolerated and why.