Text Tools·4 min read

Cleaning CMS Exports: Strip HTML Into Plain Text

Every CMS migration ends the same way. You open the export, and the words you actually need are wrapped in three layers of divs, decorated with inline styles, and sprinkled with   entities. Cleaning CMS exports is ninety percent tag removal, and doing that by hand is miserable at any scale. This guide walks through how the Strip HTML Tags tool turns markup into readable text, what the browser parser does with entities and broken tags, and the gotchas, like Word paste artifacts, that catch people on real projects.

Open the tool All insights

Why cleaning CMS exports means stripping HTML first

The words are in there somewhere.

Content rarely leaves a CMS the way it went in. A WordPress database dump wraps every paragraph in markup, a newsletter platform exports campaigns as full HTML documents, and a page builder adds wrapper divs you never asked for. When the destination is a plain text search index, a translation service, a word count, or a different CMS with its own editor, all of that has to go.

The same problem shows up outside migrations. Support teams get tickets with raw markup pasted in, analysts receive scraped product descriptions full of tags, and writers inherit old articles where the formatting fights the redesign. In each case the job is identical: keep the human readable text, discard everything the machine added around it.

A worked HTML stripping example, before and after

One paste shows the whole behavior.

Take this fragment: <h1>Q3 <em>results</em></h1><p>Revenue rose 8% & churn fell.</p> Run it through the stripper and you get: Q3 resultsRevenue rose 8% & churn fell. Two things happened. The & entity decoded into a real ampersand, which is what you want. And the heading collided with the paragraph, which usually isn't.

That collision happens because the parser reads text content without rendering layout. Block elements create visual line breaks on screen, but those breaks are a rendering effect, not characters in the text. If paragraph boundaries matter for your output, add a newline before each closing block tag in the source before you strip, and the structure survives as actual line breaks.

Word paste artifacts hiding inside exported HTML

Office leaves fingerprints.

Content that was ever pasted from Microsoft Word into a CMS editor carries a distinctive residue: mso- prefixed style attributes, o:p tags from the Office XML namespace, conditional comments, and non breaking spaces where ordinary spaces belong. These Word paste artifacts survive for years inside a database and reappear in every export.

Stripping removes the tags and attributes in one pass, which kills most of the residue. What it can't fix are character level substitutions: curly smart quotes, en style hyphens, and ellipsis characters are real text, not markup, so they pass through untouched. If your style guide wants straight quotes, plan a Find and Replace pass after the tags are gone.

Mistakes that mangle text when you strip HTML

All of these are recoverable, if you kept the source.

The stripping step itself is nearly foolproof. The mistakes happen around it, usually because something in the markup carried meaning that plain text can't hold.

Stripping before saving the links. An anchor's visible text survives but its href does not, so the destination address is gone. Collect the addresses from the raw markup first if you need them.
Expecting paragraph breaks in the output. Adjacent blocks run together, as the worked example shows. Insert newlines into the source first when structure matters.
Forgetting script and style contents. Code inside those blocks is text to the parser and can leak into your output. Delete the blocks before stripping.
Discarding the original export. Once text and markup are separated you can't reunite them. Keep the source file until the migration is verified.
Double processing entities. If your pipeline decodes entities and then strips, &lt; can turn into a rogue angle bracket that reads like a tag. Strip once, from the rawest form you have.

Habits that pay off before stripping a big HTML export

Two minutes of prep saves an afternoon.

Think of the job as keeping text losing markup, in that exact order of priority: the words are irreplaceable, the wrapping is disposable. First, run a small representative chunk through the tool and inspect the output for run together blocks and entity behavior before committing to the whole export.

Second, harvest anything the markup carries that text can't. Run the raw export through Extract URLs to pull every address out of href attributes, and stash that list next to the clean text. Third, work in batches sized to what you can visually verify, a few articles at a time, so a surprise in one template doesn't silently damage a thousand records.

Strip HTML Tags vs HTML to Markdown

Flatten, or translate.

These two solve different problems. Strip HTML Tags flattens everything into prose: no headings, no lists, no links, just words. HTML to Markdown translates structure instead, so an h2 becomes a ## heading and anchors keep their destinations in bracket syntax. If the content is going back into a structured system, convert to Markdown; if it's feeding a search index, a word count, or a plain text field, strip it.

After stripping, Word Counter gives you honest length numbers without markup inflating them, and Find and Replace handles the character level cleanup that tag removal leaves behind. Together they cover the full export to clean copy pipeline.