Strip HTML Tags
Paste HTML and get the text out of it, with paragraphs intact and script and style contents gone rather than merely untagged. It uses the browser's own parser, so comments, malformed markup and angle brackets inside attributes are all handled the way a browser handles them.
You cannot strip HTML with a pattern.
The obvious approach is to delete everything between a less-than sign and the next greater-than sign. It works on the first example anyone tries, which is why it is the most widely copied snippet on the subject, and it is wrong for reasons that only show up on real input.
HTML is not a regular language. It nests, it permits angle brackets inside attribute values, it has comments that can contain anything at all, and real-world markup is frequently invalid in ways that browsers recover from by specification. A regular expression has no recovery rules. It matches or it does not, and what survives is arbitrary.
The worst failure is the quiet one. Removing a script tag does not remove the JavaScript between the tags, because the pattern matches tags and not their contents. Strip a modern web page that way and your “plain text” contains a program.
So this parses instead, using the browser’s own HTML parser — the same one that renders every page you visit — in an inert document that never executes anything.
What the regex approach leaves behind.
- Angle brackets inside attributesAn attribute value can legally contain a greater-than sign. A pattern matching from a less-than to the next greater-than ends the tag in the wrong place, so the rest of the tag survives into your output as visible text and the content after it disappears.
- CommentsAn HTML comment can contain anything at all, including complete tags and angle brackets in any arrangement. Tag-matching patterns cut comments in half, leaving fragments of commented-out markup in the plain text, which is how internal notes end up published.
- Script and style bodiesRemoving tags is not removing content. Strip the script tags from a page and the JavaScript between them remains, so your plain text now contains a program. This is the most common and most visible failure of the regex approach, and the reason so much scraped text has tracking code in the middle of it.
- Unclosed and malformed tagsReal-world HTML is frequently invalid, and browsers recover from it by well-defined rules. A regular expression has no rules to fall back on: it either matches or it does not, and what it leaves behind is arbitrary.
- EntitiesStripping tags does nothing to entities, so the output still says & where it should say an ampersand. Decoding them is a separate step that a tag-matching pattern does not touch at all.
Five jobs that need the text without the markup.
- Content migrationMoving posts between platforms means extracting the text from one system's markup before importing it into another's. Carrying the old markup across brings the old platform's classes and inline styles with it, which then have to be found and removed from every post individually.
- Storage and indexingSearch indexes and full-text columns want words, not markup. Storing HTML means indexing tag names and attribute values alongside the content, which dilutes relevance and inflates the index for no benefit.
- Plain-text emailA well-formed message offers both an HTML and a plain-text version, and the plain-text one is what accessibility tools and text-only clients use. Generating it by stripping the HTML version is the usual approach, and it needs the structure preserved as line breaks or the result is one unreadable block.
- Word counts and analysisCounting words in HTML counts the markup, which can double the figure on a heavily formatted page. Anything that measures content — readability, keyword density, length — needs the tags gone first.
- Cleaning copied web contentCopying from a rendered page and pasting into a document brings the source's fonts, colours and spacing with it. Passing it through here first gives you the text and nothing else, which is almost always what you wanted.
Markup leaves its spacing behind.
Indented HTML carries its indentation into the extracted text as runs of spaces and tabs at the start of every line. The tidy spacing option here handles the obvious cases, and text pulled from a heavily formatted page usually wants a second pass from the AI space remover.
Web content is also a reliable source of invisible characters. Content management systems decode entities on the way out, so a zero-width non-joiner written as an entity years ago becomes a real invisible character in your extracted text. The zero-width space remover names and removes those, which matters if the text is going into a search index.
Pages published from AI drafts carry more of them than most, since the markup preserves whatever the assistant produced. The ChatGPT watermark remover covers that case specifically, and the ChatGPT text cleaner runs the whole set of passes at once when extracted text needs more than one of them.
HTML stripping questions.
How do I remove HTML tags from text?
Paste the HTML above. It is parsed with the browser's own HTML parser rather than pattern-matched, so tags, comments, script bodies and style bodies are all removed properly and the text comes out with its paragraph structure intact.
Why not just use a regular expression?
Because HTML is not a regular language, so no regular expression can parse it correctly. In practice it fails on attribute values containing angle brackets, on comments, and on malformed markup. Worst of all, removing script tags leaves the JavaScript between them in your output, since a tag pattern matches tags and not what is inside them.
Does it remove JavaScript and CSS?
Yes, contents included. Script, style and noscript elements are removed entirely rather than having their tags stripped, because their contents are code rather than content. This is the specific thing a regex approach gets wrong.
Will it keep my paragraphs?
Yes, with keep structure on, which is the default. Block elements become line breaks, so paragraphs, headings and list items stay separated rather than running together into one continuous block. Turn it off if you want everything on a single line.
Can I keep the link URLs?
Yes. Turn on keep link URLs and each address is written in brackets after its link text, so the destination is preserved rather than lost. It is off by default because most uses want the text alone.
What happens to HTML entities?
They are decoded, so & becomes an ampersand and   becomes a space. That is almost always what you want. Turning the option off re-escapes the result instead, for cases where the output is going back into HTML.
Does it handle malformed HTML?
Yes. The browser's parser applies the same error-recovery rules it uses on real web pages, so unclosed tags, mismatched nesting and stray brackets are handled the way a browser would handle them rather than producing arbitrary output.
Is this safe against XSS?
The HTML you paste is parsed in an inert document rather than inserted into this page, so nothing in it executes. That said, this is a text extraction tool, not a sanitiser: if you need to render untrusted HTML safely, use a purpose-built sanitising library rather than stripping tags.
Does it convert HTML to Markdown?
No. It produces plain text, so formatting is discarded rather than translated. Bold text comes out as text, not as text wrapped in asterisks. If you need the formatting preserved, an HTML-to-Markdown converter is a different tool.
What happens to tables?
Cell contents are extracted with line breaks between them, so the data survives but the grid does not. Plain text has no columns, so any table becomes a list of values. For anything where the structure matters, extract the table as CSV instead.
Is there a size limit?
No. Parsing happens in your browser, so nothing is uploaded. A very large document may take a moment, since the whole thing is parsed into a document tree before any text is extracted.
Is my HTML uploaded anywhere?
No. Everything runs on your device. Nothing is transmitted, nothing is stored, and closing the tab discards it.