Start here
What the strip HTML tool does
Paste HTML, press the button, and you get the text that was inside the tags. Script and style blocks go completely, contents and all, so you do not end up with a page of JavaScript where the article should be. Every other tag is deleted and whatever sat between its opening and closing halves stays.
It runs in your browser. The markup is not sent anywhere, there is no length ceiling, and there is no daily allowance to run out of. Most competing tools are free too, so the useful question is not price but exactly what each one does to the awkward cases. That is what the rest of this page is.
The exact rules
What the strip HTML pass removes and what it leaves
Four passes, in this order. Knowing the order matters, because it explains a behaviour further down this page that otherwise looks like a bug.
- Script blocks
- Removed entirely, opening tag to closing tag, including everything between them.
- Style blocks
- Same treatment. CSS does not survive into the plain text.
- Every remaining tag
- Deleted wherever it appears, opening or closing. The text between tags is kept exactly as it was.
- Four entities
- A non-breaking space becomes a normal space, and the ampersand, less-than and greater-than entities are decoded back into their characters.
How to
How to strip HTML tags in three steps
No settings and nothing to configure.
- Step 1
- Paste the HTML into the box. Full documents, a fragment copied out of a CMS, or the source view of an email all work the same way.
- Step 2
- Press Strip HTML. The work happens on your machine, so the result appears immediately and nothing is sent anywhere.
- Step 3
- Read the output before you use it, paying attention to where paragraphs join up and to any entity that came through as text rather than as a character.
The thing that surprises people
Stripping HTML does not add line breaks
Tags are deleted, not replaced. Nothing is inserted where a paragraph or a list item ended. Paste markup written on one line, like a paragraph followed immediately by another paragraph with nothing between them, and the two sentences come out joined together with no space.
In practice this matters less than it sounds, because almost all real HTML already has newlines between its tags and the whitespace outside a tag is left completely alone. Source copied from a file or a view-source panel keeps its existing line structure. Markup that arrived minified does not, and that is the case to watch for. Two competing tools offer a checkbox that turns block tags into line breaks. This one does not have that option, and saying so is more useful than letting you assume it.
The limit worth knowing
Which HTML entities the strip HTML tool decodes
Four are decoded and everything else passes through as literal text. A quotation entity stays as the word, a numeric entity stays as a numeric entity, and a copyright or euro entity arrives in your output looking exactly as it did in the markup.
One competing tool advertises more than twenty named and numeric entities. Another decodes none at all and points you at a separate decoder. Ours does four, and the honest thing is to tell you which four rather than to let you find out on the first copyright symbol. If your source is full of entities, run the output through a dedicated decoder afterwards.
A deliberate consequence
Why escaped tags appear in the output
The entity decode happens after the tag strip, not before. So if your input contains an escaped tag written with the less-than and greater-than entities, the tag-stripping pass does not see a tag there at all. Then the decode pass turns those entities into angle brackets, and the tag arrives in your output as visible text.
That is the correct behaviour for a text tool, because escaped markup in a document usually is content: a code sample in a tutorial, an example in documentation. It also means this tool is not the right way to flatten a document that has been double-escaped. Run it twice if that is what you need, and read the result both times.
The straight answer
Does stripping HTML make user input safe?
No. This is a text utility, not a security control, and the two should never be confused. One of the tools competing for this search frames the whole job around injection in user comments, which is a reasonable thing to worry about and the wrong reason to reach for a regex.
Deleting anything between angle brackets is not the same as understanding markup, and malformed or deliberately awkward input is exactly where the difference shows. If you are sanitising something that a user typed, use a real parser and a real allow-list in your application. Use this to read a document.
In practice
Who strips HTML tags, and when
Writers pulling copy out of a CMS export that arrived wrapped in markup. People moving an email or a newsletter into a document where the tags are noise. Anyone counting words in a page and needing the words without the angle brackets.
Developers use it as a quick look at what a page actually says, which is what the script and style removal is for. And it turns up constantly as a first step before another cleanup: strip the markup, then deal with whatever whitespace or hidden characters the source left behind.