File Formats & Media

Plain Text File

Definition

Plain text is a sequence of encoded characters with no formatting instructions mixed in. The extension is usually .txt, the content type is text/plain, and the only structural feature is the line break — which is not one thing but three: LF on Unix and macOS, CRLF on Windows, and bare CR in software old enough to predate OS X. Because there is no header, nothing inside the file records which encoding produced it, so a reader must be told or must guess. Some of the web's most important files are plain text under a different name: robots.txt, a .well-known verification file, a certificate chain, a log. That absence of structure is exactly why the format outlasts the applications that wrote it — a text file from 1985 opens today, while the word processor that could have written it does not.

Why It Matters

Guessing an encoding is where plain text actually hurts. A file written as UTF-8 and read as Windows-1252 renders the pound sign as two characters and every accent as a pair of symbols, and there is no error — just wrong text. Declaring text/plain; charset=utf-8 in the response settles it, and costs nothing. The second thing worth knowing is that browsers do not always show a .txt file as text: a file served as text/plain that begins with something resembling markup was, in older browsers, sometimes sniffed and treated as HTML, which is what the X-Content-Type-Options: nosniff header exists to stop. And a practical point — text has no size overhead at all, so a 40,000-word manuscript is roughly 250 KB, and compresses to about a quarter of that.

How It Works

A request for a .txt file returns Content-Type: text/plain and the browser paints the characters in a monospace face, with no download unless a Content-Disposition header says otherwise. Line endings are preserved exactly as uploaded, which matters when the consumer is a program rather than a person: a shell script with CRLF endings fails on Linux with a confusing error about a carriage return. Some files are load-bearing at fixed addresses — robots.txt must sit at the root of the domain and nowhere else, and a domain verification file must appear at the precise path the provider names, byte for byte. A UTF-8 byte order mark at the front is invisible to a person and fatal to several parsers, so leave it off unless something specifically asks for it.

Real-World Example

A small team publishes a changelog at notes.99helpers.site/changelog.txt rather than building a page for it. The file is 8 KB, opens instantly in any browser, and can be read by a script with a single fetch. On 99helpers it sits alongside the site's robots.txt at the root, and both are served as text/plain with an explicit UTF-8 charset, so the em dashes and accented names in the entries render correctly rather than as stray symbols. Each release appends a few lines and replaces the file; the previous versions stay reachable through version history.

Common Mistakes

  • Serving text without a charset parameter — the browser falls back to a locale guess, and UTF-8 content renders as mojibake with no error to warn anyone
  • Saving a configuration or script file with Windows line endings for a Unix consumer — the trailing carriage return becomes part of the last value and breaks it
  • Leaving a byte order mark at the start — it is invisible in an editor and causes a JSON parser, a shell interpreter or a CSV import to fail on the very first character
  • Putting robots.txt anywhere but the root of the domain — crawlers look at exactly one path and ignore a copy in a subfolder

Related Terms

Put a file online in seconds

Drop in a document, an image, a page or a whole static website and share the link — free, with no build step and no server to set up.

Host a file free →