Home/Text tools/HTML to text
Text toolHTML to Text
Paste HTML, get plain text with paragraphs and list structure kept as real line breaks — parsed with the browser's own DOMParser instead of a regex that strips angle brackets.
Block versus inline elements — where line breaks come from
Plain text has no tags of its own, so the converter has to decide when an element's boundary should become a line break. The rule follows how browsers render each element visually: block-level elements start a new visual line, inline elements do not.
| Element | Type | Effect on plain text |
|---|---|---|
<p> | Block | Blank line before and after |
<h1>–<h6> | Block | Blank line before and after |
<div> | Block | Line break before and after |
<li> | Block (inside a list) | One per line, with a leading - for unordered lists or a number for ordered lists |
<br> | Line break element | A single line break, no blank line |
<table>, <tr> | Block | Each row on its own line, cells separated by a tab |
<strong>, <em>, <span>, <a> | Inline | No line break — text flows straight through, styling is simply dropped |
<script>, <style> | Non-visible content | Entire contents removed, not converted to text |
Why regex tag-stripping is unsafe
A pattern like text.replace(/<[^>]+>/g, "") looks like it should work, and mostly does, until it meets real-world HTML. Three ways it breaks:
- Content inside
<script>or<style>. A regex has no idea that everything between those tags should be discarded wholesale — it strips only the angle brackets and dumps raw JavaScript or CSS straight into your "plain text" output. - Attributes containing a literal
>. Something like<a title="5 > 3">confuses a naive regex into ending the tag early, at the>inside the quoted attribute rather than the real tag boundary, corrupting everything after it. - Malformed or partial markup. Real-world pasted HTML is frequently not well-formed — unclosed tags, mismatched nesting — and a regex has no concept of a document tree to recover with, so it just produces whatever the pattern happens to match.
This tool instead hands the input to the browser's own DOMParser, the same parser that renders every web page you visit. It builds a real DOM tree, which means script and style content is properly excluded, malformed markup is corrected the same way a browser corrects it for display, and the walk through block versus inline elements is done on actual parsed nodes rather than string patterns.
Questions people ask
Are HTML entities like & and — decoded?
Yes. Since the browser's own parser builds the DOM, entities are decoded the same way they would be for on-page rendering — & becomes &, — becomes an em dash, and numeric entities like ' decode to their character too.
Does this run any embedded JavaScript from the pasted HTML?
No. DOMParser parses markup into a document without executing scripts, images do not load, and no network requests fire — it is inert by design, which is also why it is safe to paste HTML from an untrusted source here.
What happens to images?
<img> has no text content of its own, so it produces nothing in the output. If you need the alt text preserved, that would need to be added as a separate rule — currently it is dropped along with the tag.
Does list nesting work correctly?
Nested <ul> or <ol> elements are indented one level per level of nesting, so a sub-list reads as visually nested nested in the plain-text output rather than flattened to the same indentation as its parent list.