What Is a TXT File? Plain Text, Encoding, Line Endings, and Compatibility

A TXT file is character data, not a formatted page or a word-processing package

A .txt file normally contains plain text: character data and line breaks without document-level styling, page layout, embedded pictures, tables, comments, or fields. The extension describes a common convention, not one single internal encoding. A TXT file can contain ASCII, UTF-8, UTF-16, a Windows code page, or another character encoding. What appears as a letter on screen is stored as numeric values; the program opening the file needs the same encoding rule to turn those values back into the intended characters. Microsoft explains that encoding standards are numbering schemes that assign text characters to numeric values, and a mismatch can make a file look like gibberish even when the underlying bytes are intact.

TXT appears in notes, logs, configuration files, source-code-adjacent data, exports, and simple handoffs where the words matter more than document appearance. It is a strong choice when the recipient needs readable content without requiring a particular office suite. It is a poor choice when a table’s cell structure, bold headings, exact page breaks, pictures, tracked changes, or a signature line have meaning. Converting a rich document to TXT deliberately removes those features. Preserve the original DOCX, ODT, PDF, or other formatted source when visual design or editing behavior matters.

Encoding and line endings decide how TXT bytes become readable lines

Plain text has no universal built-in label that always tells a program how to decode every byte. Microsoft gives a concrete example: the numeric value 201 means the Cyrillic character Й in Cyrillic Windows encoding but displays as É when read under Western European Windows encoding. That is why a TXT file can be technically intact yet show the wrong letters on another computer. Unicode avoids many such problems because it accommodates character sets for the languages commonly used today. Microsoft says Word is based on Unicode and, when an encoding is not chosen, saves text as Unicode by default.

UTF-8 is commonly chosen for cross-system text because ASCII characters retain their ordinary byte values and Unicode characters can be represented in an 8-bit environment. Still, an encoding must be agreed with the receiving program. Saving Unicode text as a limited legacy code page can remove characters that the code page cannot display. Microsoft warns that a Unicode document containing Hebrew and Cyrillic cannot retain both scripts if saved into only one incompatible legacy Windows encoding; Word marks characters it cannot save and can substitute a closest equivalent or an out-of-context character such as a question mark. Preview before saving rather than discovering loss after a file is sent.

A text file needs a convention for the end of a line. Microsoft’s Word encoding guidance lets a user insert hard line breaks and choose carriage return (CR), line feed (LF), or both. Windows commonly uses CRLF, Unix and Linux use LF, and old classic-Mac files used CR. Modern Windows Notepad added support for Unix LF and old-Mac CR alongside Windows CRLF, which is a useful reminder that not every historical text editor handled every convention well. A line-ending mismatch can make a file appear as one long line or show stray control marks in tools that expect a different convention.

Line ending is separate from display wrapping. A text editor may wrap a long visual line on screen without inserting a line-break byte. A parser, command-line tool, fixed-width importer, or program without word wrap may require actual CR, LF, or CRLF separators. Microsoft specifically notes that hard line breaks matter for a program that does not wrap text and offers a choice of end-of-line delimiter. Before converting, ask whether the target reads text for people, for a script, or for an import pipeline. Human-readable notes may tolerate different endings; a configuration or data-processing tool may not.

Plain text gains portability by giving up formatting and document behavior

• Simple readable content: ordinary text editors and many systems can open a TXT file without a word-processing package.
• Encoding control: a deliberate Unicode choice can carry many writing systems where a legacy code page cannot.
• Predictable line-based processing: explicit CR, LF, or CRLF separators can support scripts and simple import tools.
• No formatting: bold, italics, font selection, margins, page numbering, and styles are not part of plain text.
• No embedded objects: pictures, charts, signatures, comments, and document fields cannot be represented as normal TXT features.
• Possible irreversible substitutions: saving under an incompatible encoding can replace or remove characters the target set cannot represent.

The gain is real independence from a particular office application, but a TXT file should not be described as a stripped-down DOCX with all content intact. A rich document might export its words while losing table cells, footnotes, hyperlinks, text in shapes, hidden content, and all visual hierarchy. Before using TXT as an archive or exchange format, decide whether it must preserve only words or also the information carried by layout and structure. For text-only data, it is excellent; for a visually meaningful document, retain the original alongside it.

Programs can open plain text widely, but they cannot infer every missing decision

Text editors, code editors, terminals, and many office programs can open TXT files, but they need a decoding decision when a file does not identify its encoding. Microsoft’s Word dialog allows a user to select Windows default, MS-DOS, or another encoding and preview the outcome. This is useful when opening an older file made under a different system locale. Do not choose an encoding simply because the first few English words look normal; English ASCII letters share the same values in many encodings. Inspect accented characters, non-Latin text, punctuation, and symbols before saving the decoded result.

The Unicode Consortium explains that an initial UTF-8 byte order mark is only a signature indicating that an otherwise unmarked file is UTF-8. It also warns that a BOM can interfere with a protocol or format that expects specific ASCII characters at the start, such as a #! interpreter line. Therefore “UTF-8 with BOM” and “UTF-8 without BOM” are not interchangeable for every target, even though they display the same ordinary text in many editors. Follow the consuming application’s documented expectation. For a human note, either may be acceptable; for a script, configuration, or structured data import, the first bytes can be significant.

Real TXT failures: mojibake, missing characters, one giant line, and accidental format loss

Unreadable sequences such as wrongly accented characters are usually an encoding mismatch, often called mojibake, not random file damage. Reopen the original bytes using the likely source encoding instead of saving the gibberish over the file. Microsoft’s example of 201 becoming a different glyph under another Windows code page shows why this happens. Once the intended text displays correctly, save a new copy in the agreed target encoding. If some characters are marked as unsupported during save, do not accept substitution casually: Word may replace an ellipsis with three periods or a character with a question mark. Choose Unicode or a target encoding that actually supports the required scripts.

If every record appears on one long line, check the line-ending convention and whether the viewer wraps text. Convert CRLF, LF, or CR deliberately only when the receiver requires it; do not apply a line-ending tool to an unknown binary file. If a former Word document lost headings, images, tables, or field values, that is the expected cost of plain-text export. Recover the required information from the original formatted document and express it in a suitable format rather than expecting TXT to store invisible styling. Keep original files intact while testing; a TXT export cannot reconstruct the document features it discarded.

A plain-text compatibility table for safer handoffs

Questions before treating a TXT file as the final interchange copy

Does .txt always mean UTF-8?
No. The extension does not guarantee encoding. Agree on UTF-8 or another specific encoding and test non-ASCII characters.

Why does my text look like gibberish on another computer?
The same byte values may be decoded under the wrong encoding. Reopen the original with the correct source encoding and save a tested target copy.

Why is the whole file one line?
The viewer may not recognize the file’s CR, LF, or CRLF line endings, or it may be showing visual wrap differently from actual breaks.

Should UTF-8 include a BOM?
Only if the receiver expects it. Unicode notes that a BOM can interfere with formats that require specific initial ASCII characters.

Can TXT preserve my Word tables and comments?
No. TXT preserves character data and line breaks, not word-processing structure, images, formatting, or live document features.