Plain text

Plain text is computer data represented primarily as a sequence of readable characters, without inherent instructions specifying fonts, colors, page dimensions, embedded images or other visual presentation. Plain text represents the character content of a document rather than a fixed appearance for that content.

A plain-text document may contain letters, numbers, punctuation, symbols, spaces, tabs and line breaks. How those characters appear depends on the program, font, operating system and display settings used to render them.

Plain text is commonly contrasted with formatted text or rich text, which stores additional information such as typefaces, font sizes, colors, paragraph styles, page layouts and embedded media. It is also distinguished from binary formats whose contents cannot generally be interpreted as a sequence of text characters without format-specific software.

Common examples of plain-text content include:

• source code;
• configuration files;
• command-line scripts;
• log files;
• comma-separated value files;
• email message bodies;
• documentation files;
• data-exchange formats such as JSON and XML; and
• files using the .txt filename extension.

Whether a file is considered plain text can depend on context. A file may be stored entirely as text characters while still containing markup or instructions that another program interprets. For example, HTML, XML, JSON, Markdown, wikitext and programming-language source code are text-based formats, even though their characters may have special structural meanings.

Definition

The Unicode Standard describes plain text as the basic interchangeable content of text. It represents characters rather than their particular visual appearance. The same sequence of plain-text characters may therefore appear differently when rendered by different programs or devices.

For Internet media types, RFC 2046 defines text/plain more narrowly as text that does not require the interpretation of embedded formatting commands, font specifications, processing instructions or content markup for proper display.

The term may therefore be used in two related ways:

1. Character-based representation — data stored as a sequence of characters rather than as an opaque binary structure.
2. Unformatted text — text intended to be displayed without interpreting markup or presentation commands.

Under the first meaning, source code and markup documents are plain-text data. Under the narrower text/plain meaning, HTML or wikitext would not ordinarily be displayed as plain prose because their markup is intended to be interpreted.

Plain text and rich text

Rich text, also called styled text, adds presentation or structural information to plain text. That information may include:

• font family;
• font size;
• bold or italic styling;
• text color;
• paragraph alignment;
• margins and indentation;
• page breaks;
• tables;
• images;
• hyperlinks;
• annotations; and
• document metadata.

The Unicode Consortium describes rich text as plain text combined with additional information such as font data, colors, formatting instructions or annotations.

A word-processing document may display a title in a large bold font and a quotation in italics. In a rich-text format, those visual properties are stored as part of the document. In a plain-text file, the same words are stored without a required font or layout.

Formatting may still be suggested through text conventions:

CHAPTER ONE

This is an important statement.

* First item
* Second item

The capital letters, blank lines and asterisks are ordinary characters. A reader may interpret them as a heading and list, but the file itself does not require a particular font or visual treatment.

Plain text and binary data

Computers ultimately store both text and non-text data as bytes. The practical distinction is how those bytes are interpreted.

A plain-text file is decoded through a character encoding into a sequence of characters. A binary file is interpreted according to a format-specific structure that may contain images, executable instructions, compressed data, numeric values or other non-text information.

General comparison of data representations

Representation	Primary content	Typical examples	Requires specialized interpretation
Plain text	Characters	TXT, source code, logs, CSV	A character encoding is required
Marked-up text	Characters with structural syntax	HTML, XML, Markdown, wikitext	A parser is needed to apply the markup
Rich-text document	Text with formatting and document structure	RTF, DOCX, ODT	Document software or a compatible library
Binary data	Format-specific byte structures	JPEG, PNG, MP3, executable files	Format-specific software or decoders

A binary file may contain fragments of readable text, such as metadata or filenames, without the entire file being a plain-text document.

Character encodings

Plain-text characters must be represented as bytes when stored in a file or transmitted through a network. A character encoding defines the mapping between characters and byte sequences.

Common encodings include:

• ASCII;
• UTF-8;
• UTF-16;
• UTF-32;
• ISO-8859-1;
• Windows-1252; and
• various legacy national or platform-specific encodings.

The same visible text can be represented by different byte sequences under different encodings. A program that uses the wrong encoding may display replacement symbols, incorrect accented letters or other corrupted text, commonly called mojibake.

For example, the word:

café

contains a character outside the original 7-bit ASCII repertoire. Its byte representation depends on whether the file uses UTF-8, Windows-1252 or another compatible encoding.

UTF-8 has become a widely used encoding because it can represent the complete Unicode character repertoire while remaining compatible with ASCII for the first 128 code points.

Byte order mark

Some text files begin with a byte order mark (BOM), a special character that may identify the Unicode encoding or byte order.

A BOM is commonly associated with UTF-16 and UTF-32. Some software also writes a UTF-8 BOM, although UTF-8 has no byte-order ambiguity.

Programs differ in how they handle a BOM. Some recognize and remove it during decoding, while others may display it as an unexpected character or treat it as part of the file's content.

Line endings

Plain-text files use control characters to represent the end of a line. Different operating systems have historically used different line-ending conventions:

Convention	Characters	Escape notation	Common association
Line feed	LF	\n	Unix, Linux and modern macOS
Carriage return and line feed	CRLF	\r\n	Windows and many Internet protocols
Carriage return	CR	\r	Classic Mac OS

Modern text editors frequently recognize more than one convention and can convert between them. Differences in line endings may nevertheless affect source-control comparisons, shell scripts, parsers and network protocols.

Tabs, spaces and whitespace

Plain text can contain whitespace characters, including:

• ordinary spaces;
• tab characters;
• line feeds;
• carriage returns;
• nonbreaking spaces; and
• other Unicode spacing or control characters.

Tabs do not have an inherent visual width. One program may display a tab as four spaces while another uses eight or aligns it to the next tab stop.

A sequence that appears visually aligned in one font or editor may not remain aligned when displayed with another font, tab width or line-wrapping setting.

For this reason, formats that depend on column alignment often define specific whitespace rules or use delimiters such as commas, tabs or vertical bars.

Text files

A text file is a computer file primarily intended to contain text characters. The .txt extension is commonly associated with general-purpose plain-text documents, but the extension is not required.

Other common text-based filename extensions include:

Extension	Common use	Text-based structure
.txt	General unformatted text	Free-form text
.csv	Tabular data	Delimited values
.tsv	Tabular data	Tab-separated values
.html	Web documents	HTML markup
.xml	Structured data	XML markup
.json	Data interchange	JSON syntax
.md	Documentation	Markdown markup
.css	Web presentation rules	CSS syntax
.js	JavaScript source code	Programming-language syntax
.php	PHP source code	Programming-language syntax
.lua	Lua source code	Programming-language syntax
.wiki	Wiki source	Wikitext markup

A filename extension is only a convention. The actual content and encoding determine whether a file can be processed as text.

MIME media type

The standard Internet media type for general plain text is:

text/plain

A character encoding may be identified through the charset parameter:

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

The Internet Assigned Numbers Authority maintains the official registry of media types, including types under the text top-level category.

RFC 6838 describes text/plain as the generic subtype for plain text and specifies the role of the charset parameter for applicable text media types.

The media type does not by itself require a particular filename extension.

Plain-text editors

A text editor is a program designed to create or modify text files.

Common text-editor features include:

• character-encoding selection;
• line-ending conversion;
• find and replace;
• line numbering;
• syntax highlighting;
• indentation control;
• automatic completion;
• spell checking;
• regular-expression searching; and
• integration with version-control systems.

Syntax highlighting does not change a file from plain text into rich text. The colors and styles are applied temporarily by the editor according to its interpretation of the characters. They are not necessarily stored in the file.

For example, a code editor may display keywords in blue and comments in green while the saved source file contains only the underlying characters.

Uses

Plain text is used extensively because it can be created, read and processed by a wide range of software.

Software development

Most programming-language source code is stored as text. This allows developers to:

• edit code with many different tools;
• search files efficiently;
• review differences between revisions;
• store projects in version-control systems;
• automate processing through scripts; and
• exchange source code between operating systems.

Configuration

Many programs use text-based configuration formats because administrators can inspect and edit them without specialized software.

Examples include:

• INI;
• JSON;
• YAML;
• TOML;
• XML;
• shell configuration files; and
• web-server configuration files.

Although these formats are stored as text, their syntax must be interpreted correctly by the receiving program.

Logs

Applications and operating systems commonly write event records to text-based log files. Logs may contain:

• timestamps;
• severity levels;
• process identifiers;
• request paths;
• error messages;
• diagnostic details; and
• security events.

Structured logging systems may use formats such as JSON while still storing each record as text.

Data interchange

Plain-text formats are used to exchange information between systems because their contents can be inspected and generated on many platforms.

Examples include:

• CSV;
• JSON;
• XML;
• email;
• HTTP headers;
• source-code patches; and
• command output.

Documentation

Readme files, technical notes and software documentation are often stored as plain text or a text-based markup language.

Text-based documentation can be:

• read without proprietary software;
• searched with standard tools;
• tracked through version control;
• transformed into HTML or PDF; and
• edited through automated systems.

Advantages

Advantages of plain-text formats include:

• broad software compatibility;
• relatively simple processing;
• human-readable source;
• efficient searching;
• straightforward version comparison;
• suitability for automation;
• resistance to proprietary-format obsolescence;
• low format overhead; and
• ease of transmission between systems.

Plain text can often be recovered or inspected even when the application that originally created it is unavailable.

Limitations

Plain text does not inherently preserve:

• a particular font;
• exact line wrapping;
• page dimensions;
• text color;
• complex mathematical layout;
• embedded images;
• audio or video;
• interactive controls;
• precise graphical positioning; or
• advanced document formatting.

Additional conventions or markup languages are required when those features are needed.

Plain-text interchange can also be affected by:

• unknown character encodings;
• inconsistent line endings;
• unsupported Unicode characters;
• invisible control characters;
• tab-width differences;
• normalization differences;
• bidirectional text;
• inconsistent escaping rules; and
• format-specific syntax errors.

Security considerations

Plain text is not automatically safe merely because it is human-readable.

Text may contain:

• malicious script source;
• commands intended for a shell;
• misleading Unicode characters;
• invisible directional controls;
• embedded terminal-control sequences;
• unexpectedly large lines;
• confidential information;
• passwords or access tokens; and
• data designed to exploit a parser.

Unicode source code can present security and usability risks when visually similar characters, invisible characters or bidirectional controls cause displayed text to differ from its logical character order.

Text received from an untrusted source should be validated before it is:

• executed;
• interpreted as markup;
• used in a database query;
• inserted into HTML;
• passed to a command shell; or
• processed by a security-sensitive application.

Plain text on the web

Web browsers can display resources served as text/plain without applying HTML layout rules.

For example, a server may respond with:

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

followed by:

This text is displayed without HTML interpretation.

If the same characters were served as text/html, sequences such as:

<strong>Important</strong>

could be interpreted as HTML markup rather than displayed literally.

Correct media-type declarations are important because browsers and other clients may process the same character sequence differently depending on the declared type.

Plain text and wikitext

Wikitext is a text-based markup language used to create and format MediaWiki pages.

For example:

==History==

'''Example School''' opened in 1950.

* First item
* Second item

The source is stored as text characters, but MediaWiki interprets the equals signs, apostrophes and asterisks as formatting and structural markup.

The rendered page is therefore not an unformatted display of the source. It is the result of parsing the text according to MediaWiki's wikitext rules.

To display wikitext literally instead of interpreting it, editors can use:

'''This is not rendered as bold.'''

or:

<pre>
{{Example template}}

Plain-text source and plain-text presentation are related but not identical concepts.

Text fragments

RFC 5147 defines URI fragment identifiers for text/plain resources. These identifiers can refer to portions of a text resource by character or line positions.

A line-based fragment may conceptually identify a range of lines in a plain-text document. Support for such fragments depends on the software processing the URI.

See also

• Character encoding
• Text file
• Unicode
• ASCII
• UTF-8
• Rich Text Format
• Markup language
• Wikitext
• Source code
• Text editor
• Binary file
• Data format

External links

• Unicode Standard: General Structure
• Unicode glossary
• RFC 2046: Media Types
• RFC 5147: Text/plain fragment identifiers
• IANA media-type registry
• W3C character-encoding concepts