laws & principles
Postel's law
What is Postel's law?
Postel's law, also known as the robustness principle, suggests being conservative in what you send and liberal in what you accept. This means accepting harmless variations - such as spacing, brackets, or case - while validating, normalising, and storing a canonical version. It does not mean accepting ambiguous, unsafe, or semantically invalid input just for tolerance.
Also known as: robustness principle, be liberal in what you accept, postels law
Prefer to watch?
Watch the recap 0:36
The demo
Type a phone number however you like, then submit it. One field is strict about the format; the other accepts whatever you give it and tidies it up.
Strict mode: this field only accepts "01234 567890" - digits, one space, nothing else. Try submitting the messy number above.
What this demo shows (text version)
A phone-number field, pre-filled with "(01234) 567 890" - a number any human reads instantly. In "strict" mode the field only accepts one exact format ("01234 567890"), so submitting the pre-filled value is rejected for its brackets and spaces.
In "forgiving" mode the same value is accepted: the field strips the brackets and spaces, recognises the eleven digits, and stores a tidy "01234 567890". The number and the intent are identical either way - the only difference is whether the form does the tidying or makes the person do it. That is Postel's law: be conservative in what you send, liberal in what you accept.
People type things their own way - spaces, brackets, dashes in a phone number; slashes or words in a date. Accept the harmless variation and normalise it behind the scenes, but still validate: reject ambiguous, unsafe or invalid input rather than swallowing anything. Tolerance is for formatting, not for corrupt or dangerous data. You can see and try this principle in action on this page.
In strict mode the field threw your perfectly clear number back for a stray bracket; in forgiving mode it simply took it and tidied it up. Same number, same intent - the only difference was whether the form did the fiddly bit or made you do it. That's Postel's law: strict in what you produce, generous in what you accept.
Liberal isn't limitless. "Accept anything" means accept any reasonable format, then still validate the essentials - that it is a phone number, that the card passes a checksum, that the date exists. Normalise first, then check meaning; never skip the check, and never accept input that's unsafe to store or display.
The cost of fussiness is invisible but real: every rejected "0123 456 789" is a person retyping something that was already correct, or abandoning the form. The parsing is a one-time job for you; the formatting tax, multiplied across every user, is theirs forever. Tesler's law in miniature
the system should carry it.
Postel's law guides how to handle user input: accept harmless variations like spacing or case, but validate and normalise behind the scenes - you can try this in the demo on this page. It’s not about swallowing unsafe or ambiguous data - that’s a trap. Postel's law is about tolerance for format, not for corruption, and you can test the boundary here.
Postel's law helps systems accept harmless formatting quirks while rejecting dangerous or ambiguous input - you can see and try this principle in action on this page. It’s not about being lenient with invalid data - it’s about gracefully handling harmless variations so your system stays robust and secure.
Postel's law encourages systems to accept harmless variations like spacing or case, but never to compromise on safety or validity. You can see this principle in action through the hands-on demo on this page - no screenshots, just real interaction.
Postel's law guides you to be conservative in what you send and liberal in what you accept - especially for harmless formatting - but never compromise on safety. You can see and try Postel's law in action right here: the interactive demo lets you test how to handle input variations without accepting dangerous data.
Postel's law guides you to be forgiving of minor formatting quirks - like spaces or case - but strict about semantic validity. You can see this principle in action through the interactive demo on this page, where you test input tolerance without compromising safety.
Postel's law teaches you to accept harmless variations like spacing or case while still validating and normalising input - you can see this in action on this page. It’s not about tolerating unsafe or ambiguous data - that’s what makes Postel's law so critical in real-world UX systems.