Convert HTML to TXT Online for Free

An HTML file is a set of instructions, not a stream of prose

An HTML file can arrive from a browser’s Save Page command, an email export, a help system, a content-management backup, or a downloaded report. It normally contains readable words, but it also contains element names, attributes, links, images, forms, style rules, and sometimes JavaScript. The current HTML standard is maintained by WHATWG as a living standard. It defines how a browser turns text/html bytes into a tree of elements and text nodes, including what to do with many imperfect pages. That matters because an HTML file is not simply a document with angle brackets around words.

TXT is much narrower. It stores characters and line breaks, with no built-in heading level, font, image, link destination, table grid, form state, color, or page layout. HTML to TXT therefore extracts a reading copy; it does not preserve a web page in a second form. A saved page may be 2 MB because it carries scripts, style sheets, icons, and images, while its useful article text is only a few kilobytes. The small result is useful for searching, quoting, importing into notes, or feeding a text-only system, but retain the HTML whenever the page’s evidence depends on its layout or media.

The important decision is which words count as page content

A reliable converter parses HTML into its element tree before choosing text. This is different from deleting anything that looks like <...>. HTML is not XML: its parser has its own error-recovery rules, and browsers routinely make a usable tree from missing end tags, mixed-case tags, or badly nested markup. A pattern that removes tags cannot perform that repair. It can also be fooled by a greater-than sign inside an attribute or by markup-like characters inside script data. Parser-based extraction is not a luxury; it is the difference between understanding a document and guessing at its punctuation.

There are also two reasonable but different extraction goals. A DOM property commonly called textContent gathers text nodes, which can include text in a script or style element unless the tool removes those elements first. A rendered-text approach, often called innerText in browsers, follows the displayed result more closely and can omit text hidden by CSS. Neither is automatically the right archival choice. Legal notices hidden behind a collapsed panel, screen-reader-only labels, navigation, cookie banners, and off-screen skip links may be meaningful in one job and clutter in another. Decide whether the TXT is meant to be a visible reading copy, an accessibility review, or a complete text-node dump, then inspect it.

What becomes easier, and what is permanently left behind

The loss in an HTML-to-TXT conversion is deliberate. These consequences are worth choosing before the original is discarded.

• Words become portable: a UTF-8 TXT file opens in basic editors, command-line tools, and databases without a browser layout engine.
• Links lose their destinations: the anchor words may remain, but an href is an attribute rather than visible text. A useful research export should append the URL when it supplies needed context.
• Images disappear: an image is normally an external or embedded resource, not text. Its alt value is an attribute, so a simple text-node extractor will not include it unless configured to do so.
• Tables lose relationships: cells can survive as words, but TXT has no columns or borders. Add a tab, pipe, or repeated delimiter between cells and a line break between rows, then compare the result with the page.
• Visible decoration is not recoverable: CSS font size, bold weight, color, margins, and page width explain hierarchy and emphasis but have no equivalent in ordinary TXT.
• Search can improve while proof gets weaker: plain text is excellent for finding phrases, yet it cannot prove where a phrase appeared, what it linked to, or whether a chart changed its meaning.

Browser behavior explains several surprising TXT results

HTML collapses ordinary runs of spaces and line breaks when it is rendered, but elements such as pre preserve whitespace. A converter has to make a choice for paragraphs, list items, headings, and line breaks because the raw source may place every element on a separate line while the visible page does not. The safest reading output usually inserts paragraph breaks for block content and does not wrap every line at a fixed width. Fixed wrapping can split a URL, a file path, or a long identifier, and it makes later copy-paste less faithful.

Some content shown in a browser is not a normal text node. CSS can generate labels with ::before and ::after; the HTML standard’s rendered-text rules exclude generated content. A button may therefore look as though it has a symbol or status word that never appears in an ordinary extraction. Conversely, an HTML source can carry a script’s source code even though a reader never sees it. Script and style are raw-text elements in HTML syntax, so removing only their opening and closing tags can leave the code in the TXT file. A converter should remove those whole elements, not just their tags.

Four failure patterns reveal what the converter actually did

If the result contains JavaScript such as function, tracking names, or CSS selectors, the tool stripped tags but did not remove script and style elements. Re-run it with script and style removal enabled; do not manually delete hundreds of lines before checking the setting. If the output includes a navigation menu, cookie choices, and repeated footer links, that is not a broken parser. Those words genuinely exist in the document tree. Extract only the article or main region when the tool supports selection, or remove known navigation, header, footer, and aside regions after reviewing the original.

A result that reads Français instead of Français has an encoding problem often called mojibake. UTF-8 bytes were likely decoded as a single-byte encoding at some stage. Modern HTML normally declares its character encoding with a meta charset value, and HTTP delivery can also declare one; a local TXT file has no mandatory HTML-style encoding label. Decode the source correctly, write the output as UTF-8, and explicitly select UTF-8 when opening it in an older editor. Do not repeatedly convert already garbled text: the original byte file is the place to repair the mistake.

Missing words around a picture usually mean the needed description was in alt, a caption, or text drawn inside the image. Include image alt values only when they add content rather than interface noise, and keep captions beside the images they describe. Text inside a screenshot, scan, or infographic is pixels; HTML-to-TXT cannot read it. That requires optical character recognition, then a human check for names, numbers, and small labels. Finally, if table values form one long sentence, make a structured export or rebuild the important table. Spaces alone do not retain which number belongs to which heading.

A compact record of what survives each extraction choice

Answers for a clean and defensible plain-text copy

Why does the TXT file contain code that was never visible on the page?
HTML can hold JavaScript and style rules as text inside special elements. A tag-only stripper leaves that content behind. Use a parser-based tool that removes script and style elements before collecting text.

Will HTML-to-TXT keep every link?
It can keep the clickable words, but the destination is stored in the href attribute, not in those words. Choose an option that writes URLs beside links when sources, citations, or instructions depend on where a link goes.

Why are accented letters or non-English text broken?
The source bytes or the saved TXT were interpreted using the wrong encoding. Start again from the original HTML, honor its declared character set where available, save as UTF-8, and reopen the TXT explicitly as UTF-8.

Does plain text preserve accessibility information?
Only some of it. Visible text nodes may survive, but alternative text, labels, landmarks, headings, and relationships can be lost or flattened. Use the original HTML for a real accessibility review; TXT is a reading aid, not an accessibility-tree export.

Can this conversion read the writing inside an image?
No. HTML extraction sees the image reference and perhaps its alt text, not the letters drawn in pixels. Use OCR for screenshots and scans, then compare high-risk words and numbers with the image.