is the actual article is not. A real page nests its content several levels deep inside layout wrappers. A naive text dump can't tell a post-body
from a sidebar
sitting right next to it; both are just
s. This tool looks for
, then role="main", then . It only falls back to a readability-style content score, weighing text density, link density, and class/id hints, when none of those exist.
Nav bars, footers, and cookie banners aren't markup noise. They're real text sitting in real elements. That's exactly why a markup-only strip, which is all txtfetch's API does today and all most "HTML to text" tools do, can't remove them. From the parser's point of view, "Accept cookies" and the article's opening sentence are the same kind of thing: text inside a tag. Telling them apart takes the same class/id and link-density heuristics used for main-content selection, applied in reverse to flag what to exclude.
A page with zero whitespace between two adjacent block-level elements, common in minified, generator-emitted HTML, glues into one run-on word under a plain .textContent read. "Latest newsRead more" comes out instead of two separate lines. This tool treats block-level tag boundaries as hard breaks, regardless of the source markup's own whitespace. This repo's own plain-text mirror generator had to learn that same rule the hard way.
## what-to-do-next
Got the text out and want the API call for a real URL? The panel above already has it. Extracting many pages, or pages bigger than this browser tool's 25 MB cap? [See the full web-page extraction guide →](https://txtfetch.com/extract/html)
## faq
**Does this tool upload my page or fetch a URL?**: No to both. Everything happens in your browser with an inert DOMParser. Nothing is executed, nothing is fetched, and nothing is uploaded. It genuinely can't fetch a URL for you either; that's a browser sandbox restriction (CORS) every client-side tool shares, not a missing feature. Paste the page's HTML or a copied selection instead. txtfetch's API does the fetching, via ?url=.
**How is "paste a copied web page" different from pasting HTML source?**: They land in the same box, and the tool treats them the same way once pasted. The only difference is what your clipboard carries. Select and copy text from a rendered page and your browser attaches a text/html rendering of it to the clipboard alongside the plain text. This tool reads that HTML flavor when it's present, so a copied page still extracts as structured content rather than one flat paragraph.
**Does it strip navigation, ads, and cookie banners like the API does?**: It goes further than the API does today. txtfetch's API runs Tika's HTML parser, which removes markup but not boilerplate text (see /fixes for the general version of this caller-side-cleanup point). This tool's "main content" mode is a deliberate extra step: a readability-style score that separates the article from its chrome. A toggle switches back to the naive strip, so you can see exactly what the API's response looks like today.
**Can it read Markdown out, not just plain text?**: Yes. A Markdown mode renders headings, links resolved to absolute URLs, lists, and fenced code blocks, mirroring the shape of txtfetch's API's own format=markdown response.
**What about .mhtml (a whole saved page, images and all)?**: Not supported in this browser tool. .mhtml wraps the page and its resources in a MIME envelope that needs its own decode step this tool doesn't do. Paste the page's plain .html, or a copied selection, instead.
**Is there a size limit?**: This tool reads up to 25 MB entirely in your browser. It has a node-count cap and an output cap. So a hostile or machine-generated page can't hang the tab. Larger pages, or a batch you want to automate, go through the same extraction via the API, which has no such limit.
## That was one file. The API does the queue.
This page read your HTML on your own machine. The API reads a folder of them.
[Read the quickstart →](https://txtfetch.com/docs)
[Get an API key →](https://app.txtfetch.com/signup)