Stripping the syntax is easy; deciding what to do with the information is not

Removing asterisks, hashes and backticks so the text reads cleanly is the trivial part. The real question is what happens to the information the formatting was carrying — and links are the case that proves it.

Links carry two things, and only one can survive

A Markdown link holds the text a reader sees and the address it points to. Write [read more](https://example.com) and there are two separate pieces of information in it.

Plain text has room for one. This converter renders the Markdown and takes the text content, which means it keeps "read more" and the address is gone.

That is right for some destinations and wrong for others, and there is no universally correct answer — which is the point. A word count, or a text-to-speech pass, wants the visible words and nothing else, because URLs read aloud are noise. A plain-text email needs the destinations somehow, or every reference in it becomes a dead end. Decide before you convert whether you will need the addresses later, because afterwards they are not recoverable from the output.

Images and tables

Images vanish completely. An image element has no text content, so nothing is extracted — not even the alt text, which is the one part that was written for a reader.

Tables come off worse. Strip the pipes and dashes and what remains is a run of cell values with no rows and no columns. Which numbers belonged together is simply gone, and a table that summarised something now reads as an undifferentiated list. If your document's substance is in a table, plain text is the wrong destination for it.

Code blocks and lists

Code fares better than people expect: the text comes through with its line breaks and leading whitespace intact, because that whitespace is part of the content. What disappears is the fence and the language label — so the code is readable and no longer marked as code, which matters if the surrounding prose relied on the visual distinction.

Nested lists flatten. Indentation goes, so the relationship between a point and its sub-points is lost while both remain present, which is arguably worse than losing either — the reader sees a flat sequence of claims that were meant to be hierarchical.

Why do it at all

• Pasting into a field that shows raw text rather than rendering it, where asterisks would appear literally
• Getting an accurate word count of the prose rather than the prose plus the markup
• Feeding text to something that reads it aloud or analyses it
• Preparing content for a system that has no idea what Markdown is

What to compensate for by hand

Headings and emphasis carry structure a reader can see at a glance and plain text cannot. Strip them and a well-organised document becomes a wall.

Where the plain text has to stand on its own, that is worth fixing manually — a blank line and a short lead-in sentence can do the work a heading was doing, and rewording to put the important idea first replaces what bold was signalling. Neither is automatic, and neither takes long.

Everything runs in your browser; nothing is uploaded. Since counting words in raw Markdown counts the syntax too, stripping first and then using the word counter gives a truer figure for the prose alone.