Remove HTML Tags From Text — Free Online HTML Stripper

What HTML tags are and why they end up in plain-text contexts

HTML tags are markup instructions wrapped in angle brackets: <p>, <div>, <strong>, <a href="...">. A browser renders them invisibly, converting the markup into visual formatting. Every other context — a plain-text email body, a CSV cell, a REST API string field, a database text column, a plain-text search index — sees them as literal characters. The result is content like <p>Hello <strong>world</strong></p> appearing verbatim instead of the intended “Hello world”.

The most common sources of unwanted HTML are: WordPress and other CMS editors that store post content as HTML; rich-text email clients whose “plain text” export retains inline tags; web scrapers and crawlers that return raw HTML source; copy-paste from a browser into a tool that preserves the underlying markup; and document converters that produce HTML as an intermediate format before targeting a final output.

Stripping HTML is a data-cleaning step, not a formatting preference. The tags themselves carry no information value in a plain-text pipeline — they are implementation details of the HTML rendering layer that should never have reached the text layer in the first place.

HTML entities: &   < and why they need separate handling

HTML entities are text sequences that represent characters the HTML parser would otherwise misinterpret. & represents a literal ampersand. < and > represent the angle brackets used in tags themselves.   is a non-breaking space. © is a copyright symbol. Numeric entities like   or   represent Unicode code points directly.

After removing tags, you typically want to decode entities as well. A paragraph stored as <p>Price: &lt;$50 &amp; &gt;$10</p> should produce Price: <$50 & >$10, not Price: <$50 & >$10. Failing to decode entities leaves escaped characters in the output that look wrong to any reader who did not know they were ever HTML.

The non-breaking space   deserves special attention. It is commonly used in HTML to prevent line breaks between words and to add visual spacing. After stripping tags, an   that was decoded to Unicode U+00A0 looks identical to a regular space in most editors but behaves differently in string comparison, word splitting, and some search engines. This tool decodes   to a regular ASCII space (U+0020) to eliminate that ambiguity.

Script and style blocks: why the entire content must be deleted

Removing <script> and <style> tags by stripping the opening and closing tag while keeping the content between them is wrong. The content of a <script> block is JavaScript source code. The content of a <style> block is CSS. Neither belongs in plain text output.

Consider a page that contains <style>body { font-size: 14px; color: #333; }</style>. A tag-only stripper that removes <style> and </style> but keeps the content between them leaves body { font-size: 14px; color: #333; } in the output — CSS rules presented as if they were prose. The same problem applies to inline JavaScript: removing the <script> tags without removing the code produces a block of JavaScript statements embedded in the output text.

This tool deletes the entire contents of <script> and <style> blocks, including the tags themselves. Any HTML comment (<!-- ... -->) is also removed in full, since comments are metadata for developers, not content for readers.

Preserving line structure: when to keep vs. strip newlines

HTML block elements — <p>, <div>, <h1> through <h6>, <li>, <br> — mark visual line or paragraph boundaries. When you remove the tags, those boundaries disappear unless you add a newline in their place. This tool inserts a newline when removing block-level closing tags so that paragraph text does not run together.

A <br> tag is converted to a newline rather than deleted, since its sole purpose is to force a line break. A closing </p> or </div> is followed by a newline to preserve the paragraph boundary. An opening <li> gets a newline before it so list items land on separate lines.

Inline elements — <span>, <strong>, <em>, <a> — are removed without adding a newline, since they wrap content within a line rather than separating blocks. The text that was inside the tag continues on the same line as the surrounding content.

Why regex alone cannot reliably strip HTML

The most-cited reason is that HTML is not a regular language — it can be arbitrarily nested, and nesting cannot be tracked by a finite automaton. But the practical problem for stripping is more specific: angle brackets appear inside attribute values.

Consider <img alt="Price > $10" src="img.png">. The > inside the alt attribute is a literal character in the attribute value, not the end of the tag. A naive regex like /<[^>]+>/g will match <img alt="Price > as the “tag” and leave $10" src="img.png"> as orphaned text in the output. This corrupts the output and can leave partial attribute values that look like content.

A similar problem occurs with multi-line tags and with tags whose attributes contain quoted strings that themselves include > characters. Robust HTML stripping requires either a proper HTML parser (which tracks quoted attribute values correctly) or a very careful multi-step regex that handles quoted segments separately. This tool uses a parser-based approach for that reason.

There is also the problem of special characters in attribute values that contain encoded angle brackets — < and > — which are safe to leave in the attribute value but become meaningful characters once the attribute is removed and entities are decoded.

Real-world use cases: email signatures, WordPress exports, scraped content

Email signatures built in rich-text email clients often contain spans, divs, and inline style attributes. When an email signature is extracted for use in another system — a CRM, a plain-text template, a signature database — the HTML structure comes along. Running the signature HTML through this tool produces the plain text that can be entered directly into the target field.

WordPress stores post content as HTML in its database. Exporting posts via the WP REST API or direct SQL returns the raw stored HTML, including <p> tags, <strong> spans, and any shortcode output that was rendered to HTML. Stripping the tags before passing the text to a downstream system — a search index, an AI summarizer, a content migration target — avoids the markup appearing in the wrong place.

Web scrapers commonly return full page HTML. Even after targeting a specific element with a CSS selector, the extracted content often contains nested tags from the page's template. Stripping the tags and decoding entities gives you the visible text content — the same text a user would see if they opened the page in a browser and selected all text. See also the markdown stripper if your scraping target uses Markdown formatting instead of HTML.

Tag attributes and data-* attributes: what gets removed

Every attribute on a removed tag is removed along with the tag. This includes class, id, style, href, src, alt, data-*, aria-*, and any other attribute. The attribute values are not preserved in the output.

This means link URLs are lost. <a href="https://example.com">Click here</a> becomes Click here. If the URL needs to be preserved, either copy it separately before stripping or pre-process the HTML to replace each anchor with a format like Click here (https://example.com) before running the stripper.

Image alt text is a partial exception: the alt attribute value is not preserved in the stripped output since the tool removes the entire <img> tag. If alt text matters for your use case — for accessibility descriptions, for search indexing, or for content completeness — extract it from the alt attribute before stripping. Unlike Markdown image syntax, where the alt text is the primary content and the URL is secondary, HTML image tags treat the alt text as a presentational fallback rather than the main content.