Skip to content
UX Atlas
Plate LAW·012 · LawGrid B2 · Rev. 2026-08-14

Postel's Law

Be liberal in what you accept and conservative in what you send, which for interfaces means accepting messy input and returning clean output.

LawCraft conventionIntermediate

Definition

Jon Postel's robustness principle, written for TCP implementations in the early internet standards, states that a system should be tolerant of variation in what it receives and strict about what it produces. Applied to interfaces, it argues for forgiving input handling and unambiguous output.

Craft convention. True because the industry converged on it. Breaking it costs familiarity, not correctness.

On this plate
  1. 1Definition
  2. 2Input tolerance worth building
  3. 3Conservative output
  4. 4Input worth accepting, and what to do with it
  5. 5In practice
  6. 6Local chart
  7. 7Sources
  8. 8Continue from here

Reach for this when

  • Designing any input field with a format.
  • Reviewing validation rules and error messages.
  • Auditing form abandonment.

Common mistakes

  • Over-strict validation regular expressions, especially on email and names.
  • Normalising input invisibly so the user cannot verify it.
  • Assuming your locale's format is the universal one.
  • Accepting ambiguous input and storing an interpretation without showing the reader which one you chose.

Input tolerance worth building

Each of these removes an error the user should never have been shown.

  • Phone numbers: accept spaces, dashes, brackets and country prefixes, then normalise.
  • Card numbers: strip spaces on submit rather than rejecting them.
  • Dates: accept several formats and echo the interpreted date back in an unambiguous form.
  • Email: trim whitespace, lowercase the domain, and never reject on an over-strict regular expression.
  • Names: allow apostrophes, hyphens, accented characters, single-word names and names longer than most fields allow.
  • Postcodes and addresses: accept the local format, whatever it is, and validate on the server against a real service.

Conservative output

Do

  • Echo back a normalised, unambiguous version of what you understood.
  • Show dates with a written month when the format could be misread across regions.
  • State units and currency explicitly.
  • Use one canonical representation of a value throughout the product.

Do not

  • Silently alter data in a way the user cannot see.
  • Accept ambiguous input and then guess without showing the guess.
  • Present the same value in two different formats on the same screen.

Input worth accepting, and what to do with it

Every row here is a rejection message somebody could have avoided writing.

What the user typesAcceptThen
Card number with spaces or dashesYesStrip on submit, keep the grouping visible
Phone number with the country code, brackets or dotsYesNormalise, and echo back the stored version
Email with leading or trailing spacesYesTrim silently. Nobody meant the space
Date as 1/3/26, 01-03-2026 or 1 Mar 2026YesParse, then show the interpreted date in an unambiguous format
Name with an apostrophe, accent or non-Latin scriptYesStore it as given. This is a correctness issue, not a tolerance one

In practice

  1. i.

    Card number formatting

    Checkout

    Rejecting a card number because the user typed the spaces printed on the card is a self-inflicted error. Strip the spaces, or better, auto-format as they type so the field matches the physical card.

  2. ii.

    Date echo-back

    Booking and scheduling

    Accept 03/04 in either interpretation, then display 'Wednesday 3 April 2026' beneath the field. The tolerance is invisible and the confirmation is unambiguous.

  3. iii.

    The rejected apostrophe

    Where tolerance is not optional

    A validation rule that refuses O'Neill is not strict, it is broken. Tolerance of format is a courtesy; acceptance of real names is a requirement.

Local chart

LAW·012 · Region I · Grid B2

This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.

Date PickerCMP·009 · APPLIED THROUGHText InputCMP·003 · APPLIED THROUGHAutocomplete and TypeaheadPAT·003 · APPLIED THROUGHInput ValidationPAT·007 · APPLIED THROUGHPayments and CheckoutPAT·024 · APPLIED THROUGHError MessagesWRT·002 · APPLIED THROUGHInternationalizationWRT·006 · APPLIED THROUGHForm UX ChecklistCHK·001 · CHECK YOUR WORKError PreventionHEUR·005 · RELATED CONCEPTTesler's LawLAW·005 · RELATED CONCEPTConstraintsPRIN·009 · RELATED CONCEPTForgivenessPRIN·006 · RELATED CONCEPT

Sources

Where a source establishes something narrower than the popular reading of it, the note says so.

  1. [1]

    RFC 761: Transmission Control Protocol

    J. Postel, DARPA, 1980

    Original statement of the robustness principle.

  2. [2]

    The Harmful Consequences of the Robustness Principle

    M. Thomson, IETF draft

    Argues that excessive tolerance harms protocol maintenance over time. The critique applies to protocols, not to user input handling.

Continue from here

Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.

Applies when you are designing

A CheckoutA FormAuthentication

Applied through

Where this shows up as a concrete interface decision.

Check your work

Review passes that test whether this was done properly.

Related concept

Connected closely enough to change how you apply this.