What is a TXT file?

TXT is a plain-text format you can open in any editor. It is used for moving data between programs and archiving.

The extension is .txt, and the full name is Plain Text. Both matter less than what the file can hold, which is what the rest of this page is about.

It dates from 1963. The specification is Unicode.

A format that has been readable for that long is a format worth trusting with something you want back in ten years.

It is published in full, so anyone can implement it from the document rather than by inspection, which is why it turns up in so many programs and why files written twenty years ago still open. A published specification is not the same thing as a royalty-free one: where a format wraps a codec, the patent licensing is a separate question the standard does not settle.

TXT stores its content exactly. Saving it again changes nothing, so it can be opened, edited and re-saved as often as you like without accumulating damage — which is what makes it a working format rather than a delivery one.

Notepad, TextEdit and Visual Studio Code read it, and so do most programs of the same kind.

If a file will not open, the format is rarely the problem — it is more often that the program predates it. Converting to something older is the reliable way past that, and it is what the rest of this site is for.

Every current browser reads it.

That makes it a safe thing to put on a page or attach to a message without wondering what the other end has installed.

TXT is meant to be opened and changed. Keep the file in this format for as long as the work is going on, and export from it whenever a finished copy is needed.

A TXT file is a sequence of characters. There is no header, no structure, no styling, no metadata and no version — nothing to become obsolete, and nothing that needs a program to interpret it. That is the whole of the specification, and it is why a text file written in 1970 opens today in anything and will open in fifty years in whatever has replaced it.

Everything else on this site is a format in the real sense: bytes arranged so that a particular kind of program can reconstruct something. Plain text asks nothing. It is the floor that every other format is built on top of, which is why HTML, CSV, JSON, Markdown, SRT and SVG are all, underneath, text files with conventions layered on.

Characters have to be stored as numbers, and which number means which character is the encoding. UTF-8 is the answer everywhere now, and it has the useful property that plain English text is byte-identical to the ASCII of fifty years ago.

Older files are not UTF-8, and nothing in the file says so. Text saved on a Windows machine in Western Europe is probably Windows-1252; in Central Europe, 1250; in Russia, 1251. Open one of those assuming UTF-8 and every accented letter becomes a black diamond or a pair of nonsense characters. The bytes are intact — the reader is guessing, and guessing wrong. Any decent editor lets you reopen the file with a different encoding, which fixes it instantly and without retyping anything.

Some editors write three invisible bytes at the start of a UTF-8 file to declare what it is. On Windows this is common; almost everywhere else it is considered a mistake.

It is invisible in an editor and highly visible to a program. A configuration file with a BOM fails to parse. A CSV with one has a first column header that does not match anything. A shell script with one refuses to run with an unhelpful error. If a text file is being rejected by something for no reason you can see, this is the first thing to check — "UTF-8 without BOM" is the setting you want.

Windows ends a line with two characters, carriage return and line feed. Everything else uses one, the line feed alone. Both are legitimate, and the file does not announce which it uses.

The visible symptoms are old but not gone: a Unix file opened in Windows Notepad as one enormous line, or a Windows file showing a stray marker at the end of every line in a Unix tool. Modern editors handle both silently and can convert between them. Where it still bites is version control, where a whole file appears changed because somebody’s editor rewrote every line ending, and in scripts, where a trailing carriage return becomes part of a filename and nothing works.

Longevity, first. If something has to be readable in thirty years with no assumptions about software, it should be text. That covers notes, records, transcripts, configuration, data exports and anything an archivist will thank you for.

Then tooling. Text can be searched, filtered, sorted, compared and edited by a vast number of programs that know nothing about your data. A diff between two versions is meaningful. Version control can merge two people’s changes. None of that is possible with a binary document, and it is the reason so much technical work happens in text formats that look primitive next to the alternatives.

Logs and exports run to gigabytes, and most editors try to load the whole thing into memory. A word processor will simply refuse; a general editor may hang the machine.

The tools that cope read in chunks — a proper code editor, a pager, or the command-line utilities designed for it. On any system, looking at the first and last fifty lines of a large file answers most questions without opening it: the top says what the file is, the bottom says whether the process that wrote it finished.

Converting a document to TXT keeps the words and discards everything else — fonts, layout, images, tables, headings. Sometimes that is the point: extracting the text of a PDF to quote it, search it, or feed it to something else. What is worth knowing is that a table converted to plain text usually becomes unreadable, because the alignment that made it a table was formatting rather than content.

In the other direction, converting text to PDF is a change of container, not of content. It fixes the appearance, makes the file printable, and produces something that opens the same way for everyone. The text file remains the version you can still edit, search and diff, which is why keeping both is usually right.