I Tested 16 Switch Combinations of an HTML Tag Stripper: It Reports 19 Tags but Deletes 148 Characters

Three Numbers That Keep Three Different Ledgers

Paste a block of HTML and let the page finish, and the statistics line hands you exactly three numbers: 19 tags removed, 227 source characters, 79 result characters. The trouble is that 19 and 148 are not the same kind of quantity. I lifted the template's only processing function out word for word (the file is 150 lines and 6391 bytes), drove it in Node, and ran a 13-line, 227-character sample through it. The verdict: the 19 is the summed hit count of 6 .match() calls starting at line 92, while 227 and 79 are just two .length reads on lines 146 and 147. Their difference, 148, is the number of characters that actually left the document. For every tag the tool reports, 7.79 characters quietly disappear.

Four switches define the search space: the mode (remove all versus remove listed tags), keep the text inside tags, strip comments, and squash runs of spaces. Expanded, they give 16 combinations, and I flipped all 16 cells on the HTML tag remover with the same 227-character sample. Every result is in the table below.

The 16-Cell Matrix: Only One Switch Moves the Counter

Groups 9 through 16 were all run with the same four tag names typed into the field. Of the four switches, only keep-content moves the tag counter: the reported number sits at 19, 14, 10 or 5 across the four regions of the matrix, comment stripping and space squashing never touch it, and only the output length reacts to those two switches. Flip keep-content off and the report falls from 19 to 14 while the deletion climbs from 148 to 181 characters.

Figure 1: each region uses the cell with comment stripping and space squashing both on.

Switch Keep-Content Off and Deleted Tags Leave the Count

Turning this switch off in all mode sends the code down a different path. The six block tags collected at line 96 are eaten by the whole-block pattern on line 98 before the counter starts at line 102, so block tags never enter the reported number. On my sample the report drops from 19 to 14, and the missing five are exactly <style>, </style>, <script>, </script> plus the <div> that only exists inside a string literal.

Take a 54-character test string: <style>.a{}</style><script>var a="<div>";</script>text. With keep-content on, the page reports removing 5 tags and prints 17 characters. With it off, everything except the four characters of text is gone, yet the statistics line writes 0 for tags removed.

The Listed-Tag Mode Matches by Prefix

After a tag name is typed in, the pattern assembled on line 115 is '<'+tag+'[^>]*>', with nothing anchoring the tag name's start. Fill in p and run it on a 40-character string such as <p>paragraph</p><pre> code</pre><param name="x">: the tool reports 4 tags removed and hands back 12 characters, because <pre> and <param name="x"> are deleted together with the intended <p>, while the closing pattern insists on an exact </p\s*> and leaves stray closing tags as residue: 28 characters vanished while the counter reported only 4. Type i instead and a 69-character string is cut down to 10, because img, iframe and input are all hit by that prefix.

One Missing Separator and the String Comes Back Untouched

The field label promises comma-separated names, but the checklist's worked examples use the ideographic comma. The split written on line 109, split(/[,，\s]+/), only recognises the half-width comma, the full-width comma and whitespace; the ideographic comma is not on the list. Type the pair as the copy shows it, script、style, and the split yields a single token that gets sanitised into scriptstyle: nothing matches, 0 tags are removed, and an 84-character input comes back character for character. Write the same pair as script,style,div and the run removes 6 tags and deletes 43 characters. An empty field is quieter still: a 28-character input produces 0 reported tags and 16 characters of output, while that same string under all mode reports 2 and returns 5 characters. A count of 0 does not mean the output equals the input.

The Word All Carries Less Weight Than It Looks

The general pattern requires < to be followed immediately by an ASCII letter and demands a closing >, so under the default switches 7 categories of markup sail through untouched: the 15 characters of <!DOCTYPE html>, the 21 of <?xml version="1.0"?>, the 4 of <3.5, the 2 of <>, the 3 of </>, the 4 of an unterminated <div, and the 10 of < b>x</ b>. Escaped markup is never decoded either: the 11 characters of <div> match 0 times and reach the output, while   and U+00A0 sit outside everything this page processes. Comparison operators can be swallowed as tags too: the 8 characters of <b && c> are one such victim.

What the Comment and Whitespace Switches Really Do

Comment removal is the non-greedy match on line 85: it stops at the first closing marker it finds. An unterminated comment of 17 characters is preserved verbatim, and a nested one loses 19 characters to the match while 6 characters of residue stay in the output.

Whitespace is three .replace() calls on line 136 that squash runs into a single space rather than deleting them. A Chinese run of 9 characters becomes 7. A leading full-width space U+3000 turns 9 into 8: only that first character goes. Four U+00A0 characters stay four and three U+200B characters stay three; a lone newline is never merged, and only a run of three newlines collapses 5 characters down to 3; each CRLF pair takes 6 characters down to 4. Code indentation suffers most: a <pre> block is 25 characters once its tags are stripped, compression leaves 19, and the first line's indentation is trimmed away entirely.

Running a Whole Page Through It

Then I switched to a real page skeleton of 19 lines and 569 characters. The default switches report 32 tags removed and hand back 277 characters; the first line is still <!DOCTYPE html>, with only 52 Chinese characters and 53 code symbols inside. Turning keep-content off alone changes the report to 26 tags and the output to 88 characters, and the 189 characters separating the two runs are precisely the bulk of the CSS / JS / JSON-LD source that the first version preserved.

No Batch Entry and No Surprise on the Second Pass

There is no batch entry on this page: line 70 reads the value of a single input box, line 44 provides a single output area, and the template holds 0 file pickers, 0 FileReader calls and 0 iteration loops, so a second snippet means re-selecting everything by hand. The 6 call sites ship no throttle, so pasting 5000 characters re-runs 12 .replace() passes for every keystroke. Pouring the output back in for a second pass is mostly boring: across 11 samples, 10 come back byte for byte unchanged, and only <<b>hi> keeps being rewritten - the first pass leaves 4 characters of <hi>, the second pass leaves 0 characters. Meanwhile the second run's counter almost always displays 0: a snapshot of this pass, not a record of progress.

Checking All 22 Lines of Product Copy

I took the 22 marketing lines written for this tool at lines 1144 through 1152 of config/tools.php and judged each against the measurements: 7 agree with reality, 15 conflict. The conflicts cluster in three claims - the promise to 提取纯文本 (extract plain text), the promise to remove 仅移除指定标签 (only the listed tags), and the option described as 可选去除连续空格和换行 (optionally removing consecutive spaces and newlines). The older post on this site about removing HTML tags is an experience note; this one does not repeat it, and only fills in the switch matrix and the counting rules.

Frequently Asked Questions

Q: If it reports 19 tags, did it remove 19 tags?

No. On the same 227-character sample, keep-content on reports 19 and off reports 14, while the characters deleted climb from 148 to 181: whole-block removal runs before the counter does, so the ratio between reported tags and deleted characters jumps from 7.79 to 12.93.

Q: I only typed p - why did <pre> disappear too?

The pattern on line 115 has no prefix boundary, so p also hits pre and param; on the closing side the tool demands an exact match, which means opening tags get deleted while their closing tags survive as residue.

Q: The result still contains escaped markup. What now?

This page contains 0 entity decoders and 0 DOM parsers, and everything it does is string replacement, so a form like < reaches the output untouched.