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. Most of the cleanup is 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 it keeps and drops, and the gotchas, like Word paste artifacts, that catch people on real projects.

Open the free Strip HTML Tags 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 two lines with a blank line between them: Q3 results, then Revenue rose 8% & churn fell. The & entity decoded into a real ampersand, and the heading and paragraph stayed apart instead of running together.

That comes from the Keep line breaks option, which is on by default. Headings, paragraphs, lists and other blocks get a blank line between them, list items and divs start a new line, <br> becomes a line break, and table cells are separated by tabs. Untick it and the whole fragment collapses to one line with single spaces, which suits a search index or a spreadsheet cell better than a document.

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, attributes and comments in one pass, which kills most of the residue, and non breaking spaces come out as ordinary spaces. 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.

Losing link destinations. By default an anchor keeps only its visible text. Tick Keep link URLs as: text (URL) and each address is written in brackets after its link text, or collect the addresses first with the URL Extractor.
Flattening text a person will read. With Keep line breaks unticked, every paragraph merges into one long line. Leave it on unless the destination really wants a single line.
Expecting images to leave a trace. Images, iframes and SVGs produce no text, so alt text stored in attributes disappears unless you tick Show image alt text, which writes it as [Image: alt text]. Script and style blocks are dropped completely, so code doesn't leak into the output.
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 and 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 check the line breaks, entities and links before committing to the whole export.

Second, harvest anything the markup carries that text can't. Run the raw export through the URL Extractor to pull every address out of href and src 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 Converter

Flatten, or translate.

These two solve different problems. Strip HTML Tags keeps the line structure but drops the formatting: headings become plain lines, list items lose their bullets, and links become plain text unless you keep their URLs. The HTML to Markdown Converter 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.