This site has spent fifteen years taking HTML off text. These tools do the jobs on either side of that: tidying markup you want to keep, and lifting the useful parts out of markup you do not.
Paste straight from Word or Google Docs and get HTML your CMS will accept: the headings and lists survive, the twelve kilobytes of Microsoft markup do not.
Pull every link out of a page as a plain list, with the anchor text if you want it, as CSV or Markdown, sorted and deduplicated.
Encode or decode HTML entities like &, < and >.
Turn plain text into HTML with paragraphs and line breaks.
Build HTML tables with the rows and columns you need.
The front page is a blunt instrument, and deliberately so. You give it markup, it gives you back the words, and everything in between is gone. Most days that is exactly right.
Some days it is not. When a colleague sends over a page from a word processor, the headings and the lists are the work. What you want removed is the eleven kilobytes of Microsoft housekeeping wrapped around them, and only that. These tools are for those days: a scalpel where the front page is a hammer.
There is a famous answer on Stack Overflow about why you should not parse HTML with regular expressions. It is right, and markup out of Word is the reason it is right. Nothing about that file is well-formed, tidy or predictable.
So these tools do not try. They hand the markup to the parser already sitting in your browser, the one that has spent two decades learning to make sense of whatever the web threw at it, and work on the result. It is more honest and considerably harder to fool.
It could, for a paragraph. Then you try it on a real page, and you are counting tokens, waiting for an answer, and reading the output twice to check that nothing was quietly reworded on the way through.
These tools give the same answer every time, in the moment you stop typing, for a file of any size, without an account. Some jobs want judgement. Removing forty thousand mso- declarations is not one of them.