text/html HTML Flagship

What it's for

text/html identifies HTML documents — the type that makes a browser render markup as a web page rather than displaying it as raw text or triggering a download. It's the single most fundamental MIME type on the web: every page you've ever visited in a browser was served with (or the browser assumed) this Content-Type, and it's what tells the browser "parse this as a DOM, execute any scripts, apply any stylesheets, render it visually."

Browsers will sometimes try to guess and render content as HTML even without this header present (a legacy behavior called "MIME sniffing"), but relying on that guessing is fragile and a real security concern — always set this header explicitly for actual HTML content.

Format & syntax

Content-Type: text/html
Content-Type: text/html; charset=utf-8

Unlike application/json, HTML doesn't have a universal default charset assumption, so explicitly declaring charset=utf-8 (or matching whatever encoding your document actually uses) matters more here — a mismatch between declared charset and actual file encoding is a real, if now less common, source of garbled text ("mojibake") on pages.

How it's used in practice

• Every standard web page response — the default Content-Type for server-rendered pages, static HTML files, and most web framework responses that aren't explicitly returning JSON, XML, or another format.
• Email HTML bodies — HTML-formatted emails use text/html as one part of a multipart/alternative message, paired with a text/plain fallback for clients that don't render HTML email.
• Single-page application (SPA) initial load — even JavaScript-heavy SPAs still serve an initial text/html document (usually a minimal shell) that then bootstraps the JavaScript application, since the browser needs a real HTML document to begin parsing and executing scripts from.
• iframe embedded content — content rendered inside an <iframe> needs to actually be text/html for the browser to render it as a nested page rather than offering it as a download or displaying raw markup.

Common mistakes & gotchas

• Missing or mismatched charset causing garbled characters — if the declared charset doesn't match the actual byte encoding of the file (a UTF-8 file declared as ISO-8859-1, or vice versa), special characters and non-ASCII text render as garbled symbols, a classic and still-occurring "why does my page show weird characters" bug.
• Relying on browser MIME sniffing instead of setting the header explicitly — some servers or misconfigured responses omit Content-Type and rely on the browser guessing the content type from the response body — this is unreliable, can vary across browsers, and has real security implications (MIME sniffing has historically been exploited in certain XSS-adjacent attacks), which is exactly why X-Content-Type-Options: nosniff exists as a header to disable this guessing.
• Serving templated HTML fragments (for AJAX/HTMX-style partial updates) with the wrong type — partial HTML responses meant to be injected into an existing page via JavaScript should still generally be text/html (or sometimes deliberately something else if the client expects a specific wrapper format), and getting this wrong can cause the receiving JavaScript to mishandle the response.
• Forgetting HTML entity escaping isn't a MIME type concern but is easy to conflate — setting the correct text/html Content-Type doesn't itself protect against XSS or ensure proper escaping of user-generated content; that's a separate, application-level concern entirely unrelated to which MIME type is declared.

Comparison & FAQ

Why does my page show garbled characters even though the file looks fine in my editor?

Check for a charset mismatch between what's declared in the Content-Type header (or a <meta charset> tag) and the actual byte encoding the file was saved with — this is the most common cause of "mojibake" garbled text rendering.

Do I need to explicitly set Content-Type: text/html, or will the browser figure it out?

You should always set it explicitly. Relying on browser MIME sniffing (guessing content type from the response body) is unreliable and has real security implications; many modern security setups explicitly disable this guessing via the X-Content-Type-Options: nosniff header.

What's the difference between text/html and application/xhtml+xml?

application/xhtml+xml requires the document to be well-formed XML — a single unclosed tag breaks the entire page. text/html is parsed by HTML's much more lenient, error-tolerant parsing rules, which is why it remains the overwhelmingly dominant choice.

Does setting Content-Type: text/html protect against XSS?

No — that's an unrelated, application-level concern about properly escaping user-generated content before it's inserted into HTML. The MIME type only controls how the browser interprets and renders the response, not whether the content itself is safely constructed.