Pricing Dashboard Sign up
Recent
· 9 min read · MDisBetter

8 URL to Markdown Tools and How to Compare Them Yourself

Most "URL to Markdown" benchmarks pick easy pages and grade on a pass/fail axis. Real conversion happens on a long tail of awkward inputs: documentation sites with code blocks, news articles wrapped in three layers of ad scaffolding, JS-rendered SPAs that fetch nothing useful on first paint, and Reddit threads where the actual content lives behind shadow DOM and infinite scroll. This guide presents eight tools by what they are, then six kinds of page that expose the differences between them, so you can run the comparison yourself on pages that match your work.

The eight tools, by what they are

Disclosure: we built one of them. The descriptions below say what each tool is and how you use it, not how well it scored: there are no scores in this guide.

What the type of tool tells you before any test

Some differences follow from how a tool is built, and you can know them before converting a single page:

Six pages that expose the differences

Run every candidate on the same six kinds of page, on the same day. Each one stresses a different failure mode.

A Wikipedia article

For example en.wikipedia.org/wiki/Markdown: long-form prose, heavy internal linking, an infobox, references. Check that the article body comes out clean, that the infobox and citation links don't clutter the text, and that the references survive as a list with no navigation chrome around them.

API documentation

For example docs.stripe.com/api, which ships syntax-highlighted samples in several languages per endpoint. Check that code comes out as fenced blocks with language hints (```python, ```ruby) rather than plain paragraphs: for any LLM workflow consuming the output, flattened code is a serious downgrade.

A news article

For example a New York Times article, wrapped in newsletters, related-story cards, ad scaffolding, video players, and "continue reading" gates. Check that the article body is isolated from the chrome and that photo captions don't break into the text. Expect only the part an anonymous visitor can see.

A JS-rendered page

Pick a single-page app from your own list whose raw HTML is a near-empty shell until JavaScript runs (view the page source to check). This is the JavaScript test: a tool that doesn't run a browser returns little or nothing here.

A GitHub README

Content that was already Markdown before it was rendered to HTML, with badges, anchor tables of contents, and embedded SVGs. It should round-trip almost untouched: check that Markdown-native elements come back as Markdown rather than HTML-ish fragments.

A Reddit thread

Heavy JavaScript, nested comment trees, vote widgets, removed posts, lazy loading. Check how much of the comment hierarchy survives beyond the post itself.

Scoring the six pages

Score each output from 0 to 5 on four axes: Cleanliness (no junk, no nav cruft), Structure preservation (headings, lists, tables intact), JS handling (does the actual content come through on JS-rendered pages), Code block formatting (fenced blocks with correct language hints). Score against the page as you see it in your browser, and note why you took each point off. For a fuller method with five page categories and a grid per category, see how to benchmark URL to Markdown tools.

Choosing by the shape of your work

Once you've scored your pages, the shape of your workflow often decides more than a point or two of quality:

For RAG pipelines specifically, see the URL-to-Markdown for RAG guidance page and the runnable Trafilatura-based recipe in scrape a website to Markdown for RAG.

Frequently asked questions

Which of these eight tools is the best?
There's no answer that holds for every workload. The tools differ first by type (local library, API, web tool, no-code scraper), then by how they handle the pages you actually convert. Run the six kinds of page above, or your own equivalents, through the two or three tools that fit your workflow, and score the outputs yourself.
Why include html2text, a library, next to hosted tools?
Because it's the classic baseline. html2text is good at what it does: convert clean server-rendered HTML to Markdown locally. It has no content extraction and no JavaScript rendering, so on modern pages you pair it with a fetcher, a cleaner, and a headless browser. Keeping it in the comparison shows what the hosted tools add on top.
How often should I re-run the comparison?
Before you commit to a tool, when you switch, and every few months if the output feeds something important. Tools update often and live pages change, so keep the same six URLs where they still exist and compare like with like.