Strip HTML, rules published

Four substitutions applied in sequence, and the sequence is load-bearing. Script blocks are removed with their contents. Style blocks are removed with their contents. Every remaining tag is deleted wherever it appears, opening or closing, and nothing is put in its place. Then four entities are decoded.

Publishing the order is not decoration. Two of the behaviours on this page follow from it and from nothing else, and a reader who knows the order can predict the output of any input without running it. That is the property a deterministic tool should offer and most pages on this term do not.

Pass 1

Script elements, opening tag through closing tag, contents included. Nothing of the JavaScript reaches the output.

Pass 2

Style elements, treated identically. CSS does not survive.

Pass 3

Any remaining angle-bracketed construct is deleted and replaced with nothing at all. Text between tags is untouched, and so is whitespace outside them.

Pass 4

Exactly four entities decoded: non-breaking space to a space, then ampersand, less-than and greater-than to their characters.

Pass three deletes and does not substitute, so block structure is not converted into line breaks. Two adjacent paragraphs written with no whitespace between the tags emerge as a single run of text with no separator. This is the most consequential difference between this engine and the two tools on this term that discuss the question, both of which offer a block-to-newline option.

The mitigation is structural rather than optional. Whitespace outside tags passes through untouched, so any source that was formatted with newlines between its tags retains exactly that line structure. The failure case is narrow and identifiable in advance: minified markup, a single-line database field, or HTML pasted out of a log. For those inputs the paragraph boundaries are genuinely absent from the output and have to be restored by hand.

Non-breaking space, ampersand, less-than, greater-than. Everything else is left as literal text: the quotation and apostrophe entities, copyright, euro, every numeric and hexadecimal reference, and the entire long tail of named entities.

For comparison, one tool on this term claims more than twenty named and numeric entities and names copyright and euro among them, while another strips entities rather than decoding them and directs the reader to a separate decoder. Neither position is wrong. What would be wrong is implying a coverage this engine does not have, since the discrepancy surfaces on the first copyright symbol a user pastes.

There is no configuration, so the judgement happens after the output exists.

Step 1

Establish whether the source is formatted or minified, because that single property determines whether paragraph structure survives.

Step 2

Run the pass. Execution is local, with no upload, no network request and no length ceiling to work around.

Step 3

Inspect for the four known residues: joined text, undecoded entities, decoded escaped markup, and title text at the head of the document.

Because entity decoding is pass four and tag removal is pass three, an escaped tag in the input is invisible to the stripper and then made visible by the decoder. A document containing escaped markup produces output containing literal angle brackets where that markup was.

This is correct rather than incidental. Escaped markup in a source document is nearly always content: a code sample in a tutorial, an example in API documentation, a snippet quoted inside a support article. Treating it as content preserves the author's meaning. It does mean that a double-escaped document requires two runs, and that the second run will remove what the first run revealed, which is worth knowing before you conclude that the tool is inconsistent.

The pass recognises angle-bracketed constructs by pattern, not by grammar. On well-formed markup the two approaches agree. On malformed markup they do not, and the disagreement is not always predictable. A comment containing a greater-than sign terminates the match early and leaves a fragment. An attribute value containing a greater-than sign does the same. Head content is not special-cased, so title text passes into the output like any other text node.

One competing tool states the same limitation about its own implementation in almost these words, and another concedes that it is not completely reliable because applications produce different markup. Both are being accurate. A regex tag strip is an excellent text utility with an identifiable degradation curve, and pretending otherwise would be the only real error available here.

One of the pages competing for this term frames the use case around users injecting markup into comment fields. The concern is legitimate and the instrument is wrong. Everything in the preceding section is a reason: pattern matching on angle brackets degrades on exactly the malformed input an attacker constructs deliberately.

Sanitisation requires a parser that builds a tree, an explicit allow-list of elements and attributes, and enforcement at the point the content is rendered. None of those properties is present in a four-substitution text transform, and none of them can be added to one. This route is for reading documents.

First in a text pipeline. Every downstream operation is cheaper once markup is gone: a word count no longer counts attributes, a hidden-character scan no longer wades through tag internals, a whitespace pass has ordinary text to work on. Content migrations, CMS exports, newsletter source and scraped article bodies are the routine inputs.

It does not belong anywhere a guarantee is required. Not as a security boundary, not as a converter between formats, and not as a substitute for a parser where a parser is what the situation needs. Within its actual scope it is deterministic, local, unlimited, and fully described by the four passes at the top of this page.