Last month I helped a colleague tidy up an event description. He selected everything in the post editor of a WeChat official account dashboard and pasted it into my document. It looked like three paragraphs, but every sentence had <p> and </p> wedged between its parts, and each paragraph dragged a string of behind it, stretching the line spacing. I ran the editor's clear formatting command once; the tags disappeared, the whitespace characters stayed exactly where they were, and the PDF export came out with an ugly ragged edge.
This has happened to me more than once, and it took a while to see the pattern: the problem is not copy and paste as an action, it is that the same content exists in three different forms, and pasting the wrong form hands you the wrong characters.
The same text has three forms inside a system
The first is the rendered result, the version the browser paints on screen and your eyes see: font size, line spacing and indentation are all computed from styles, and none of that presentation information travels with a copy as readable text. The second is HTML source, where markers such as <strong>, <br> and <img> are the skeleton; this is what you get from view page source. The third is plain text, where every tag is gone and only the characters remain.
The software you paste into picks one of these representations for itself. If it picks the source, tags become ordinary characters in the body. If it picks the rendered result, spacing is reflowed by its own style rules. The test I settled on is simple: turn on hidden characters right after pasting and you can see which one you got.
| Form | What it actually contains | What happens when you paste it into Word or code |
|---|---|---|
| Rendered result | Visible content plus paragraph spacing | Spacing follows the destination's own styles and will not match the original page |
| HTML source | <p>, <br>, <div>, attributes, comments <!-- --> |
Tags are treated as body text, the character count inflates and string literals break |
| Entity form | , ", &, “ |
A quote shows up as " and double quotes inside code close early |
| Plain text | Only characters and line breaks | All structure (hierarchy, lists, emphasis) is lost |
When to keep tags, and when to strip them completely
Early on I stripped everything down to the bone, until I noticed that this shovels out useful material along with the junk. I reduced the test to one question: is there a parser downstream.
If the text is going back into a web page, an email template or a rich text editor, then <p>, <ul> and <li> are not junk, they are part of the content structure. Bold carries emphasis, lists carry parallel items, tables carry comparisons; strip them and the reader is left guessing. In that case I would rather delete only named tags from the source: clear out scripts, styles and comments that have nothing to do with the body, and hand the remaining markup back untouched.
The other way round: if the only downstream consumers are people or a search index, I strip it clean. Four typical cases: body text that goes into a search box for full-text lookup; string literals that must be pasted back into code; exports to CSV or plain-text archives; and word counts for proofreading. In all four, tags only add noise, and in code especially, a single stray < makes the whole line fail to parse.
The order I settled on
- Confirm whether you copied source or rendered output. If you got the wrong form, do not keep working, copy it again.
- Decide what happens to the tags: if the text goes back to a web page, remove only named tags (say script, style and div on their own); if only people will read it, drop all of them and keep the text, with comments cleared at the same time.
- Once the tags are gone, what is left is mostly whitespace characters. I handle markup with HTML Tag Stripper, which can remove only the tag names you list (script, style, div, for example) or strip everything and keep the text, comments included. I leave collapsing runs of spaces and line breaks to the next step, because that step has better options for full-width spaces, tabs and blank lines.
- Handle entities separately. Do not assume the tag step will turn
back into a normal space; those are two different layers. When I see a string starting with & I note it down and leave it for the entity decoding step. - Finally, tighten the edges with Text Cleaner and check the before-and-after difference with Word Count.
Step five is not ceremony. Once I collapsed a whole draft into a single line, and only the difference showed that the paragraph separators had been swallowed too. A clean strip should remove the character count of the tags; if the newline count also drops to zero, you turned on too many options. Comparing numbers is the only way to catch it on the spot.
Specific traps I have hit
Inside a WeChat article body, indentation is often not real spaces but a run of . A tag stripper will not turn that into ordinary spaces for you, so pasting it into code gives you a pile of characters nothing can explain.
The next trap is nesting. If you delete <div> by plain string replacement, opening tags that carry a class attribute survive, the closing tags are removed cleanly, and the leftover looks fine until you paste it somewhere else and the layout shifts. So I would rather hand named-tag removal to a tool built for the job than type replacements by hand.
Table content is the worst category. Once a table is flattened to plain text, the row-to-column mapping exists only in your eyes; I have seen six columns of a stats table copied into Notepad and come out as two. At that point I keep the HTML, or ask for the raw data as CSV, because no amount of clean tag stripping brings the structure back.
Q: I copied from a web page into Word, the tags are gone, so why can't I delete the spaces?
Because they are not ordinary spaces. Web pages use plenty of non-breaking and full-width spaces, and Word displays them as blanks while still counting them as characters, so clear formatting does nothing. Clean by character type, not by formatting.
Q: Does stripping tags affect the article's word count?
It affects the count you are looking at, but it should not affect the body text itself. Tag characters were never part of the content, so a lower count is normal. If the drop is close to half the document, you deleted more than tags.
Q: Can I remove only scripts and styles and keep every body tag?
Yes, that is exactly what named-tag mode is for. Enter the tag names, such as script, style and div, and everything else stays put; the result can go straight back into the editor.
Q: Can I delete tags by hand with find and replace?
For a few, yes; for many, do not force it. Angle brackets are special characters in regular expressions, one wrong escape deletes too much or too little, and deleting too little looks clean, so it is hard to catch before you hand the work over.
Q: What should I watch out for when handling HTML comments?
Comments often hold the previous version and internal notes. They do not affect display, so people miss them. When extracting body text, clearing comments along with the tags is the safer move.
Back to that event description: the final version had no tags and none of those strings that begin with &, but I only stripped everything after confirming that people were the only downstream readers. My colleague later needed a version pasted back into the dashboard, and that one came from the original source with only named tags removed, so the structure survived. Same text, two versions, and the destination decided which.