text/plain Plain Text Flagship

What it's for

text/plain identifies content as unstructured plain text — no markup, no parsing rules, no rendering beyond displaying the literal characters. It's the simplest, most unopinionated text-based MIME type, and its main practical value is as a safe default: content that a browser will display as raw readable text rather than attempting to render, execute, or download as a specific file format.

It's also the required fallback part in multipart/alternative HTML emails, error message bodies from APIs that don't have a more specific format, and any situation where you genuinely just want to communicate "here's some readable text, don't try to interpret it as anything more structured."

Format & syntax

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

No structural requirements — any sequence of characters is valid text/plain content. The main variable worth being deliberate about is charset, since plain text with non-ASCII characters (accented letters, emoji, non-Latin scripts) needs correct encoding declared to render properly.

How it's used in practice

• API error responses and simple text output — endpoints that return a simple message rather than structured JSON (health check endpoints, simple status pages, basic logging output) often use text/plain for its straightforward, no-parsing-required simplicity.
• Email plain-text fallback — HTML emails are typically sent as multipart/alternative containing both a text/html and a text/plain version, so email clients that don't render HTML (or users who prefer plain text) still get a readable message.
• robots.txt and similar plain configuration files — files meant to be both human-readable and simply parsed line-by-line (robots.txt being the most common web example) are served as plain text rather than a more structured format.
• Displaying source code or logs inline — viewing raw source code, log files, or configuration files directly in a browser (rather than downloading or syntax-highlighting them through a dedicated viewer) relies on text/plain to show the literal content without HTML interpretation.

Common mistakes & gotchas

• Using text/plain when a more specific type would be more useful — if your content actually has real structure (CSV data, JSON, markdown), using the more specific corresponding MIME type gives clients (and browsers) more useful information to act on, like triggering appropriate syntax highlighting or parsing behavior — reach for text/plain deliberately, not as a lazy default.
• Serving actual HTML or script content as text/plain by mistake — a misconfiguration that causes browsers to display raw markup as literal visible text (angle brackets and all) instead of rendering it, usually the result of a server defaulting to text/plain unexpectedly for a response that was supposed to be text/html.
• Charset issues with non-ASCII plain text content — the same encoding mismatch concerns as HTML apply here; if you're serving plain text with non-English characters, an incorrect or missing charset declaration can produce garbled output.
• Assuming text/plain implies "safe to render literally with no security concerns" — while text/plain won't be parsed as executable markup by a browser, that doesn't mean arbitrary user-supplied plain text is automatically safe in every context it might later be inserted into (like being interpolated into HTML elsewhere without escaping) — the MIME type itself doesn't provide any escaping guarantee for downstream use.

Comparison & FAQ

When should I use text/plain instead of a more specific text type?

When the content genuinely has no meaningful structure you want a client to act on — a simple message, raw log output, or truly unstructured text. If your content has real structure (CSV, JSON, markdown), a more specific MIME type gives clients more useful information.

Why is my HTML content showing up as literal text with visible angle brackets?

The response was very likely served as text/plain instead of text/html by mistake — check the actual Content-Type header being returned, since this is a classic misconfiguration symptom.

Is content served as text/plain safe from XSS concerns?

The browser won't execute or render it as markup, which removes one class of risk in that specific display context — but if that same text is later inserted into HTML somewhere else without proper escaping, it can still become a vector for issues; the MIME type itself doesn't guarantee safety across every downstream use.

Do I need to set a charset for text/plain content?

If your content includes non-ASCII characters, yes — an incorrect or missing charset can cause those characters to render incorrectly, the same encoding concern that applies to HTML and other text-based formats.