HTML to Markdown: Turning a Saved Page Into Something Worth Reading
Open any .html file you've saved from the web in a text editor and the first thing you'll
notice is how little of it is the article. Fifteen hundred lines of nav menus, cookie banners, tracking
pixels, inline <style> blocks, and <div class="wrapper-outer-container">
nesting six levels deep — wrapped around maybe forty paragraphs of actual writing. Paste that into a chat
assistant and you'll burn most of your context window on markup that means nothing to the model.
Converting HTML to Markdown flips that ratio. The tags that carry meaning get translated; the tags that only carry layout get dropped. What comes out is a document with the same shape as the original page — headings, lists, tables, links, code blocks — in roughly a tenth of the characters. Upload a file above and you'll have it in a couple of seconds. Free, no sign-up, nothing stored.
How HTML Tags Map to Markdown
Markdown was designed as a shorthand for a subset of HTML, so most of the translation is close to one-to-one. Knowing the mapping tells you exactly what to expect in the output:
<h1>through<h6>become#through######. Heading depth is preserved literally, which matters more than it sounds — a model asked to summarise section by section needs to know which headings are siblings.<ul>,<ol>and nested<li>become dash and number lists with indentation carrying the nesting.<table>becomes a pipe table, provided the table is a real data table. Tables used purely for layout — still common in email HTML and older sites — convert into something structurally valid but semantically useless.<a href>becomes[text](url), so the destinations survive rather than leaving you with orphaned anchor text.<code>and<pre>become backticks and fenced blocks. This is the single biggest reason developers convert docs pages this way — snippets stay snippets.<strong>,<em>,<blockquote>map to their obvious equivalents.<script>,<style>,<meta>, inlinestyle=attributes, class names, data attributes — all discarded. None of it survives, and none of it should.
A Saved Page Is Not the Same as Clean HTML
There's a real difference between an HTML file that a person wrote and an HTML file that a browser dumped, and it shows up immediately in the output.
Hand-authored HTML — a static site export, a documentation build, an email template, a report generated by a reporting tool — tends to be tidy and semantic. Headings are headings. Paragraphs are paragraphs. These convert almost perfectly.
A page saved with Ctrl+S from a modern site is a different animal. You get the post-JavaScript DOM, complete with the sticky header, the related-articles rail, three newsletter prompts, and a footer sitemap with eighty links. All of that is legitimate HTML, so it all converts. The output is correct — it's just got the page furniture in it. Two habits help: use your browser's reader mode and save from that, or convert first and delete the top and bottom of the Markdown before you use it. Skimming and trimming takes under a minute and noticeably improves whatever you do next.
When the File Converts to Almost Nothing
Occasionally you'll convert a saved page and get back a title and two lines. That's not a failure of the converter — it's a single-page app.
Sites built with React, Vue, Angular and friends often ship an HTML shell that is genuinely empty:
a <div id="root"></div> and a script tag. The content you saw in the browser was
assembled by JavaScript at runtime and never existed in the file. Depending on how you saved it, you may
have captured the shell rather than the rendered result. Open the file in a text editor and search for a
sentence you remember reading — if it isn't there, the converter can't invent it.
The fix is to save the rendered DOM instead (in Chrome DevTools, right-click the <html>
node and copy the outer HTML into a new file), or to skip the file entirely and use
Web2Txt, which takes a live URL, loads
the page properly, and returns Markdown. That distinction is worth holding onto: this page converts an
HTML file you already have, while Web2Txt fetches a page you don't.
The Relative Link Problem
This one catches people out. A page that links to /docs/getting-started or
../api/reference.html is relying on the browser knowing what domain and directory it came
from. Once the file is off its server, that context is gone. The converted Markdown will faithfully
contain [Getting Started](/docs/getting-started) — a link that now points nowhere in
particular.
For LLM work this usually doesn't matter, because you care about the prose and the link text, not whether
the URLs resolve. But if you're building documentation you intend to publish, or a knowledge base where
cross-references need to work, check the output and either rewrite the paths or strip the links. Image
src attributes have the same issue, which is why an offline page's images tend to come through
as broken references.
Markdown or Plain Text for an HTML File?
Choose Markdown when the page's structure is part of what you want. Documentation with code samples and a
heading hierarchy. A tutorial with numbered steps. A comparison article built around a table. An email
newsletter with sections. In all of those, the # and the pipes and the fenced blocks are
carrying real information, and an HTML to Markdown converter for LLM workflows is doing
exactly what you want.
Choose HTML to plain text when you only want the words — building a corpus, feeding a classifier, indexing for search, or running any pipeline where syntax characters are noise. There's a format toggle at the top of this page that switches between the two and carries your selected file across, so converting the same page both ways and comparing costs you one upload.
What People Actually Do With This
- Feeding docs to a coding assistant. Save the pages of a library's documentation, convert them to Markdown, and paste them alongside your GitHub repository as text. The model sees both the API surface and your usage of it, and the code blocks stay intact on both sides.
- Migrating a site. Static site generators eat Markdown. Converting legacy HTML pages is often the fastest first pass of a CMS migration, even if you tidy up afterwards.
- Archiving articles for later analysis. Markdown files are small, diff-able, and greppable in a way that a folder of saved HTML never is.
- Turning email templates into readable content. Marketing HTML is table-soup; the Markdown version is the actual message.
- Building prompt libraries. Reference material in Markdown drops straight into a system prompt or a RAG index without further processing.
The token counter under the output is the practical bit here. A documentation page that looked short in the browser can be surprisingly heavy once tables and code blocks are included, and knowing the number before you paste beats finding out from a truncation error.
Frequently Asked Questions
How do I convert an HTML file to Markdown?
Upload the .html or .htm file above and it comes back as Markdown, downloadable as .md. Free, 50 MB per file, no account. Headings map to # levels, lists stay nested, links keep their URLs in [text](url) form, and code blocks stay fenced.
Does it keep the links and their URLs?
Yes — that is the main reason to pick Markdown over plain text here. Every anchor converts to [label](href), so the destinations survive. If you are archiving documentation or auditing where a page points, that is the difference between a useful record and a paraphrase.
Can I convert a live URL instead of a saved file?
Not from this page. Web2Txt takes a URL, fetches the page and returns Markdown in one step. This page is for HTML you already have on disk — saved articles, exported newsletters, generated reports, or output from a local build.
Is this a reasonable way to migrate a site to a static generator?
For the content, yes. Prose, headings, lists, tables and code blocks convert cleanly enough to commit and edit. What it will not do is rebuild your information architecture, rewrite internal links to new paths, or extract front matter — those are the parts of a migration that stay manual regardless of which converter you use.
What happens to tables and code blocks?
Tables become pipe tables and fenced code blocks stay fenced, both of which usually survive well because the source HTML marked them explicitly. The common casualty is syntax highlighting expressed through per-token <span> classes — the code is correct, but the language hint that drove the colouring is often not recoverable, so add it back manually if it matters.
Other Formats and Tools
HTML is one of the formats File2Txt handles — upload anything and it works out what to do. If you know what you've got, go straight to PDF to Markdown, Word to Markdown, JSON to Markdown, or XML to Markdown. For tabular exports, CSV to Markdown builds pipe tables from delimited data.
For code, there's the GitHub to text converter, a GitLab version, and a local folder converter that never uploads anything. There's also a longer piece on preparing documents for LLMs if you want the general argument rather than the HTML-specific one.
Repo2Txt is built and maintained by v12hero, an independent developer building privacy-first native and web apps.