application/xhtml+xml XHTML Common

What it's for

application/xhtml+xml identifies XHTML documents — HTML markup that follows strict XML well-formedness rules (every tag closed, all attributes quoted, exactly one root element) rather than HTML's much more lenient, error-tolerant parsing. It emerged during a period (early 2000s) when the web platform was pushing toward stricter XML-based standards, though that direction was later largely abandoned in favor of HTML5's more forgiving parsing model, which is why XHTML today is a niche choice rather than a mainstream one.

Format & syntax

Content-Type: application/xhtml+xml

The document itself must be valid, well-formed XML in addition to being valid HTML markup — self-closing tags require the trailing slash (<br /> not <br>), attribute values must always be quoted, and a single parsing error anywhere in the document breaks the entire page render, unlike HTML's error recovery.

How it's used in practice

• Legacy sites built during the XHTML era — some older sites, especially ones built in the mid-2000s when XHTML was actively promoted as best practice, still serve content with this type or a .xhtml extension.
• Systems requiring guaranteed well-formed markup — certain automated content pipelines or systems that need to reliably parse/transform HTML with standard XML tooling sometimes deliberately use XHTML for that guarantee, since arbitrary "real world" HTML is notoriously inconsistent and hard to parse reliably with generic XML tools.
• Content that's also valid as both HTML and XML — some content is deliberately authored to be served as either text/html or application/xhtml+xml depending on context, taking advantage of XHTML's stricter guarantees when parsed as XML while still working as ordinary HTML elsewhere.

Common mistakes & gotchas

• A single markup error breaking the entire page — unlike HTML's lenient parsing (which recovers from many kinds of malformed markup gracefully), a document served as application/xhtml+xml that isn't well-formed XML will fail to render at all, showing a raw parsing error instead of the page — a much harsher failure mode than HTML developers are typically used to.
• Assuming XHTML is the "correct" or "more standard" choice today — this was genuinely the prevailing best-practice guidance in the mid-2000s, but HTML5's approach (well-defined lenient parsing rather than requiring strict XML) won out as the dominant modern standard; there's rarely a compelling reason to choose XHTML for new projects today.
• Serving XHTML-formatted markup with a text/html Content-Type (or vice versa) — this is actually fine and common (browsers will parse the same well-formed markup leniently as HTML), but it's worth understanding that the strict XML parsing behavior only kicks in when the Content-Type is actually application/xhtml+xml — writing XHTML-style markup doesn't get you the stricter validation unless you also serve it with the matching type.

Comparison & FAQ

Should I use XHTML for a new website today?

Generally no — HTML5's lenient parsing model is the dominant modern standard, and XHTML's strict all-or-nothing parsing behavior offers little practical benefit for most projects while adding real fragility risk.

What happens if my XHTML document has a markup error?

The entire page fails to render, showing a parsing error instead — a much stricter failure mode than HTML5's error-tolerant parsing, which will recover from many kinds of malformed markup and still display something.

Is writing XHTML-style markup (self-closing tags, quoted attributes) the same as using this MIME type?

No — you can write markup that follows XHTML conventions while still serving it as text/html, in which case it's parsed with HTML's lenient rules regardless of how strictly it's written. The stricter parsing behavior only applies when the Content-Type is actually application/xhtml+xml.

Why did XHTML fall out of favor?

The strict "any error breaks the whole page" behavior proved too fragile for the messy, real-world content management systems and varied authoring tools that generate most web content, and HTML5's approach of precisely defining lenient parsing behavior (rather than requiring strict validity) became the more practical, widely adopted path forward.