· 6 min read
To remove HTML tags from text, delete everything between the angle brackets, drop script and style blocks together with their contents, turn paragraph and line-break tags into real line breaks, and decode entities such as & back into the characters they stand for. Paste the markup into a tag remover and copy the plain text out. What it cannot do is keep information that only the tags carried: where a link pointed, the grid of a table, or the description in an image's alt attribute.
TL;DR: tags, comments and script or style blocks are removed, paragraphs and list items become separate lines, and the common entities are decoded. Link addresses, image alt text and table structure are lost, a few rarer named entities such as © stay as written, and a literal less-than sign in your text can be mistaken for the start of a tag. It is a text extractor, not a security sanitiser.
We ran the AstralText remover on small inputs to see where the line falls, rather than describing what a tag remover ought to do. The results below are what that tool returned.
| In the markup | In the plain text | Notes |
|---|---|---|
| <p>One</p><p>Two</p> | One, then Two on the next line | Block tags become line breaks, so paragraphs do not run together |
| <li>One</li><li>Two</li> | One and Two on separate lines | The bullets themselves are gone |
| <script>x()</script>, <style>p{}</style> | Nothing | Removed with their contents, not just their tags |
| <!-- draft note --> | Nothing | Comments are removed entirely |
| <a href="https://x.com/a">Docs</a> | Docs | The address in href is lost |
| <img alt="A chart"> | Nothing | Alt text is dropped |
| <td>a</td><td>b</td> | ab | Cells in one row run together |
| Tom & Jerry | Tom & Jerry | Common entities are decoded |
| © and é | © and é | Rarer named entities are left as written |
Deleting only the tags from a page leaves the code between them as visible text, so a cleaned article ends with a screenful of JavaScript or CSS. A correct remover treats script and style as containers whose insides are not prose, and removes the whole element. The same logic applies to comments: invisible on the rendered page, they become readable the moment the markers go, which is why they are best removed with their text.
Two things go wrong in a naive strip. If only the tags are deleted, <p>one</p><p>two</p> becomes onetwo, because nothing marks the boundary any more. Turning closing paragraph, heading, list-item and row tags and each <br> into a line break keeps the shape. The second problem is entities. HTML writes an ampersand as & and a non-breaking space as , so tag removal alone leaves those sequences in the text. They have to be decoded as a separate step. The WHATWG HTML standard defines the full list of named character references, and it is long, which is why a small decoder covers the common ones and not all of them.
Source: WHATWG HTML Standard, named character references
No, and the difference matters if the output goes back into a web page. Stripping tags turns markup into text for reading, searching or counting. Sanitising untrusted HTML so it is safe to display is a different job, and the OWASP guidance on cross-site scripting is clear that hand-rolled pattern matching is not a defence. If you are going to put the result back into a page, escape it on output or use a maintained sanitiser, and treat this tool as a way to read, not a way to protect.
Source: OWASP, Cross Site Scripting Prevention Cheat Sheet
Page source from a CMS export, a newsletter or an email body is often not public yet. The remover runs in the browser tab, so the markup is not sent anywhere. To confirm it for any tool, load the page, go offline and run it again.
Try it: remove HTML tags from text
Related: How to remove Markdown formatting from text
Related: How to clean AI-generated text before you publish it
Paste the markup into a tag remover and copy the plain text. It deletes every tag, drops script, style and comment blocks with their contents, turns block tags and line breaks into new lines, and decodes common entities.
No. Only the visible link text remains, and the address in the href attribute is lost. Extract the URLs first if you need them.
A less-than sign followed later by a greater-than sign looks like a tag, so everything between them is removed. Comparisons and code in the input can be affected, so check the result or write those characters as < and > first.
The common ones are: ampersand, less-than, greater-than, quotes, non-breaking space, and numeric and hex references. Rarer named entities such as © are left as written.
No. It is built for reading and extracting text. For untrusted HTML that will be displayed, escape on output or use a maintained sanitiser.