TXT File Documentation

---

Technical details

Feature	Value
Full name	Plain Text File
File extension	.txt
MIME type	text/plain
Format type	Plain text (unstructured character stream)
Developer	None — universal, predates any single vendor (ASCII/teletype era)
Introduced	.txt suffix standard since early MS-DOS/CP-M (late 1970s–1980s)
Open standard	Yes
Character encodings	ASCII, UTF-8, UTF-16 LE/BE, Latin-1 (ISO-8859-1), Windows-1252, legacy code pages
Default (modern)	UTF-8, usually without a BOM
Line endings	LF 0A (Unix/macOS), CRLF 0D 0A (Windows), CR 0D (classic Mac)
Byte-order mark	Optional at offset 0: UTF-8 EF BB BF, UTF-16 LE FF FE, UTF-16 BE FE FF
Formatting	None (no fonts, styles, colours, tables or images)
Metadata	None stored in the file
Compression	None
Magic number	None (only an optional BOM at offset 0)
Related extensions	.text, .log, .md, .csv, .ini, .nfo
Specification	Unicode Standard; IANA text/plain media type

What is a TXT file?

A .txt file holds plain text: a sequence of characters with no embedded formatting, fonts, colours, images or layout. It is the lowest-common-denominator document, supported unchanged by essentially every computing platform since the dawn of personal computing; the .txt suffix has been the standard for plain text since the CP/M and MS-DOS era of the late 1970s and 1980s. There is no vendor, no version and no specification for the container, because there is no container. Its MIME type is text/plain.

That absence of structure is exactly what makes this format worth a close look. A word-processor file has a header, streams and formatting to describe; a text file has none of that. Everything that actually varies inside a “plain” text file comes down to two invisible decisions: which character encoding maps its bytes to characters, and which line-ending convention marks its line breaks. Those two choices are the entire subject of the format, and they are the source of nearly every problem people hit with .txt files.

Bytes versus characters: why encoding exists

A file on disk is a run of bytes, each an 8-bit number from 0 to 255. Text is a run of characters. An encoding is the rule that converts between the two. Nothing in a plain .txt file records which rule was used, so a reader must be told, or must guess. Guess wrong and the same bytes decode to different characters. This is the fundamental fact about text files: the bytes are unambiguous, but their meaning as text is not, unless the encoding is known.

ASCII and the single-byte encodings

The oldest encoding still in daily use is ASCII, which assigns characters to the values 0 through 127 only: the English letters, digits, common punctuation, the space, and a block of control codes below 32 (including the line-ending characters). ASCII uses just 7 bits, so every ASCII byte has its high bit clear. It cannot represent an accented letter, a currency symbol beyond $, or any non-Latin script.

To cover more characters within a single byte, the values 128 through 255 were pressed into service by a family of single-byte encodings, each defining that upper half differently. Latin-1 (ISO-8859-1) covers Western European letters. Windows-1252 is Microsoft’s near-superset of Latin-1 that fills a few unused slots with typographic characters such as curly quotes and the em dash; it is the classic “ANSI” encoding of older Windows files. These encodings agree with ASCII for values 0–127 and diverge above it, which is why a file is fine until the first accented character and then goes wrong. When a reader decodes bytes with the wrong single-byte or multi-byte set, the visible result is mojibake: text like é where é was meant, or stray boxes and question marks.

UTF-8, UTF-16 and the Unicode encodings

The single-byte encodings top out at 256 characters, far too few for the world’s scripts. Unicode assigns a number (a code point) to every character, and its transformation formats say how to store those code points as bytes.

UTF-8 is the dominant modern encoding and the one to prefer. It is variable-width: code points use one to four bytes. Crucially, the code points 0–127 encode as a single byte identical to ASCII, so any pure-ASCII file is a valid UTF-8 file. Characters above that use two, three or four bytes, always with the high bit set, following a self-synchronising pattern that lets a decoder tell where each character begins.

UTF-16 stores each code point in two bytes (occasionally four, via surrogate pairs). Because a 16-bit value spans two bytes, it comes in two byte orders: little-endian (UTF-16LE, low byte first) and big-endian (UTF-16BE, high byte first). Windows uses UTF-16LE internally for text, which is why some Windows-exported .txt files are UTF-16 rather than UTF-8, and why such a file viewed as if it were single-byte shows a null byte (00) between every visible character.

The byte-order mark and encoding auto-detection

Since a text file does not name its encoding, editors either detect it or fall back to a default. The one explicit hint the file may carry is a byte-order mark (BOM): a few bytes at offset 0 that a writer can prepend to declare the encoding.

BOM bytes	Encoding it marks
EF BB BF	UTF-8
FF FE	UTF-16 little-endian
FE FF	UTF-16 big-endian

For UTF-16 the BOM does real work: it tells the reader the byte order (which of the pair comes first). For UTF-8 the byte order is fixed, so the UTF-8 BOM is purely a signature saying “this is UTF-8”; it is optional and often omitted, and some tools (especially on Unix) dislike it because those three bytes then appear as stray characters in programs that do not strip it. Most .txt files have no BOM at all. When there is none, an editor auto-detects: it checks for a BOM, then looks for byte patterns that are or are not valid UTF-8, then falls back to a platform default such as Windows-1252. Detection is heuristic and can be fooled, which is why an editor sometimes opens a file in the wrong encoding and shows mojibake until you manually pick UTF-8 and reopen. Choosing the correct encoding changes only the interpretation, never the bytes on disk.

Line endings: LF, CRLF and CR

The second invisible variable is how a line break is stored. Plain text marks the end of a line with one or two control characters, and three conventions grew up on different systems:

Bytes	Name	Platform
0A	LF (line feed, \n)	Unix, Linux, modern macOS
0D 0A	CRLF (carriage return + line feed, \r\n)	Windows, DOS, many internet protocols
0D	CR (carriage return, \r)	Classic Mac OS (pre-2001)

The two-character CRLF is a holdover from teletype and typewriter mechanics, where a carriage return moved the print head to the left margin and a line feed advanced the paper by one line; DOS and then Windows kept both. Unix collapsed the pair to a single LF, and old Macs used a lone CR. A mismatch is behind the familiar bug where a Unix file (LF-only) opens in an old Windows Notepad as one enormous line with no breaks, because that editor was looking for CRLF and never saw the CR. Modern editors (current Notepad, Notepad++, VS Code) understand all three and usually show and convert between them.

What a text file cannot store

By definition a .txt holds only characters. It has no way to record a bold run, a font, a colour, a heading level, a table, a hyperlink or an embedded image, because none of those are characters. It also stores no metadata: no author, no title, no creation date inside the file (the file system may track dates, but the bytes do not). This is why “converting” a text file to a Word document or PDF does not add information; it only wraps the same characters in a container that can hold formatting. Formats that build lightweight conventions on top of plain text, such as Markdown for headings and emphasis, CSV for tabular data, and LOG files for timestamped records, are all still just text: the structure lives in agreed-upon character patterns, not in any binary format. A richer alternative such as RTF is a different format that encodes formatting as text control words, so it is no longer plain text even though it looks textual.

Frequently asked questions

Why does my text file show garbled characters like é or boxes?

The editor decoded the bytes with the wrong encoding. The file is probably UTF-8 opened as Windows-1252, or vice versa. Reopen it and explicitly choose UTF-8 (modern Notepad shows the encoding at the bottom right; Notepad++ and VS Code have an encoding menu with “reopen with encoding”). The file’s bytes are fine; only the interpretation was wrong.

Why is my whole text file on a single line?

It uses Unix line endings (a lone LF, 0A) and you opened it in an editor that expected Windows CRLF. The editor never found a carriage return, so it drew no line breaks. Open it in current Notepad, Notepad++ or VS Code, which recognise LF, CRLF and CR and can convert between them.

Should a text file have a byte-order mark?

For UTF-16 a BOM is useful because it declares the byte order. For UTF-8 it is optional and often best omitted: the three bytes EF BB BF are a signature only, and some Unix tools treat them as stray characters at the start of the file. Include a UTF-8 BOM only when a specific consumer (some Windows programs) needs it to detect UTF-8.

References

• The Unicode Standard (latest version)
• IANA — text/plain media type registration
• MDN Web Docs — Character encoding

Feedback

Was this page helpful?

Yes No

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.