Why HTML Forgives —
The History and Meaning of Error-Tolerant Design

Your Broken HTML Still Works

Try this. Open the following markup in a browser.

<h1>Hello
<p>This is a paragraph
<p>This is <strong>also</p> a paragraph

The <h1> is never closed. The <strong> opens inside a paragraph that closes before the strong does. Syntactically, this is a mess.

And yet, the browser renders it. The heading appears as a heading. The paragraphs appear as paragraphs. The bold text is bold. No error message. No blank screen. Just a best-effort interpretation of what you probably meant.

In virtually every other programming context, this would be unthinkable. A missing semicolon in JavaScript kills the entire script. A syntax error in Python halts execution. So why does HTML get to be this lenient? The answer isn't sloppiness or technical debt. It's a deliberate, philosophical design choice — one that shaped the web as we know it.

Postel's Law — Where Forgiveness Began

In 1980, Jon Postel — one of the engineers building the foundational protocols of what would become the internet — wrote a single sentence into RFC 761, the TCP specification, that would echo through decades of technology design.

The Robustness Principle, as it came to be known. Postel was working on ARPANET, a network where nothing was guaranteed. Packets got corrupted. Implementations diverged. Different machines spoke slightly different dialects of the same protocol. If every node insisted on rejecting anything less than perfect input, the network would barely function.

So Postel proposed a compromise: send your best, accept their worst. If you can understand the intent of a message, process it. Don't let the perfect be the enemy of the functional.

A decade later, Tim Berners-Lee built a hypertext system at CERN that would inherit this philosophy — not because he explicitly referenced Postel's Law, but because the same pragmatic thinking led to the same pragmatic conclusion.

The Tag Soup Era — What Forgiveness Wrought

HTML's tolerance wasn't a planned feature. In the very beginning, HTML didn't even have a formal specification. When Berners-Lee built the first browser — called WorldWideWeb — at CERN in 1990, he made a practical decision: if the browser encounters a tag it doesn't understand, skip the tag and render the content inside it. That way, documents written with newer tags would still display something useful in older browsers.

This one implementation choice had staggering consequences. It meant any browser could render any HTML, regardless of version mismatches. New features could be added to the language without breaking the old web. Forward compatibility and backward compatibility — two of the web's greatest strengths — arrived not as deliberate specifications but as side effects of that simple rule: ignore what you don't understand.

But in the late 1990s, this tolerance mutated into chaos. Netscape Navigator and Internet Explorer were locked in a war for market share, and their weapon of choice was proprietary HTML. <marquee>, <blink>, <font> — tags that no standard defined poured into the language. Browsers competed not just to support these tags, but to render even the most mangled markup into something that looked intentional.

The result was what developers came to call "Tag Soup" — a web built on markup so syntactically incorrect that no formal parser could process it, yet so universally rendered that nobody noticed. Studies in the late 2000s suggested that over 95% of web pages contained HTML syntax errors. Every single one of them displayed just fine.

That's the paradox of forgiveness. It lowered the barrier to entry so far that anyone could publish a web page — a teenager in Notepad, a researcher with no coding background, a small business owner copying HTML from a forum. It also meant the average quality of HTML on the web was abysmal. Both of these things are true, and both are consequences of the same design choice.

XHTML 2.0 — The Strict Path Rejected

The W3C's answer to Tag Soup was strictness. In 2000, they published XHTML 1.0 — HTML reformulated under XML's grammar rules. Tags must be lowercase. Attributes must be quoted. Empty elements like <br> need a closing slash. The language was the same; the discipline was tighter.

XHTML 1.0 was fine. The web community adopted it without much resistance. Then the W3C pushed further.

XHTML 2.0 proposed adopting XML's draconian error-handling model: one error, and the parser stops. The page goes blank. A single unquoted attribute would prevent an entire website from rendering. In theory, this would force developers to write perfect markup. In practice, it would break 95% of the existing web.

Web developers revolted. Not with protests — with code. In 2004, engineers from Mozilla, Apple, and Opera formed WHATWG (Web Hypertext Application Technology Working Group) and began drafting what would become HTML5. Their founding principle: the web is built on tolerance, and that tolerance is a feature, not a flaw.

In 2009, the W3C officially discontinued XHTML 2.0. The strict path was dead. HTML's forgiving nature had won — not on aesthetic grounds, but on practical ones.

HTML5 — Codifying the Guesswork

HTML5 did something remarkable. It took the error-recovery behavior that browsers had been implementing independently — each with slightly different guesses — and wrote it into the specification.

Before HTML5, two browsers might handle <b><i>text</b></i> differently. After HTML5, the spec defines exactly how to recover from that nesting error, and every conforming browser must do it the same way. The guesswork became a standard. Forgiveness got rules.

This wasn't a license to write sloppy code. HTML validators still exist. Clean markup still matters for accessibility, SEO, and maintainability. But HTML5 declared a priority: the user's experience comes first. If the choice is between punishing the developer and protecting the visitor, protect the visitor.

Meanwhile, JavaScript Does Not Forgive

The contrast is worth sitting with. HTML is a declarative language — you describe what you want ("this is a heading," "this is a paragraph"), and the browser figures out how to display it. JavaScript is an imperative language — you give the browser step-by-step instructions, and it follows them exactly. Or it doesn't follow them at all.

In HTML, a missing closing tag is silently corrected. In CSS, an unrecognized property is silently skipped. In JavaScript, a single reference to an undefined variable halts the entire script.

<!-- HTML: errors are recovered -->
<p>Paragraph one
<p>Paragraph two  <!-- no </p>, both still render -->

// JavaScript: errors are fatal
console.log("This prints");
undefinedFunction();  // script stops here
console.log("This never prints");

As Jeremy Keith observed in Resilient Web Design: HTML and CSS degrade gracefully — they break partially. JavaScript breaks totally. And yet, the modern web increasingly depends on JavaScript for basic content delivery.

In 2015, NASA redesigned its website as a JavaScript-dependent single-page application. Until three megabytes of JS downloaded and executed, visitors saw nothing but a black screen. The content — text and images that HTML could have delivered instantly — was fetched through JavaScript. On a slow connection, with an ad blocker interfering, or on an older device, the site was simply... empty. The forgiveness of HTML would have guaranteed at least something visible. JavaScript's strictness guaranteed nothing.

What Forgiveness Means Now

HTML's error tolerance carries a message that goes beyond engineering. It's a statement about who gets to participate.

HTML has always been a language you could learn in an afternoon. Write some tags in a text file, open it in a browser, see something on screen. No compiler, no build step, no dependencies. If you got something wrong, the browser helped you out — it showed what it could and quietly discarded what it couldn't. That low barrier is what allowed the web to spread to every corner of the world. Not just developers. Researchers, students, hobbyists, small business owners — anyone with a text editor and a curiosity to publish.

Today, in a world of React and Next.js, we rarely write raw HTML. We write JSX that compiles to HTML. Errors are caught at build time, before the browser ever sees them. In a sense, the strict world XHTML 2.0 envisioned has arrived — just not in the browser. It lives in our toolchains.

But the HTML that the browser ultimately receives is still the forgiving language. That layer is still there. And as long as it is, the web can never become an all-or-nothing platform. If JavaScript fails to load, if CSS breaks, HTML still renders. It renders imperfectly, partially, maybe even ugly — but it renders. That last-resort tolerance is the essential characteristic that separates the web from every native platform.

The next time you write a line of HTML — even inside JSX, even inside a framework — remember what you're writing in. A language that bends instead of breaking. A language designed not to punish, but to include. That design choice was made thirty-five years ago, and it's the quiet contract that keeps the web the most forgiving platform on earth.