How to Benchmark URL to Markdown Tools on Your Own Pages
URL to Markdown tools are built for different kinds of page, so a score table made on someone else's pages tells you little about yours. The benchmark worth having is the one you run on the pages you actually convert. This guide gives you the method: five page categories to sample, five axes to score, a grid to fill in per category, and the pitfalls that skew a comparison. If you first want to know what the main tools are, start with 8 URL to Markdown tools and how to compare them.
Why run your own benchmark
Web pages differ more than converters do. A documentation page lives or dies on its code blocks, a news article on how much ad scaffolding gets stripped, a forum thread on whether the comment hierarchy survives, a single-page app on whether its JavaScript runs at all. A tool built for one of these shapes can be weak on another, and a single total score hides that. Pages also change: the page you convert today may not be the same page in six months, so any published result ages. Your own test set, scored the same way each time, is the result that answers your question.
Step 1: sample five page categories
Pick three to six URLs per category, chosen to look like your real workload. Skip a category you never convert, and give more pages to the ones you convert most.
- Documentation: API references and tutorials, ideally with code samples in several languages, MDX components, and parameter tables (think Stripe API docs, FastAPI, React, Tailwind, MDN, Kubernetes).
- News: articles wrapped in newsletters, related-story cards, ad scaffolding, video players, and "continue reading" gates.
- Wiki: server-rendered long-form prose with infoboxes, reference lists, and dense internal linking (Wikipedia, Wiktionary, a MediaWiki manual, the Arch Linux wiki).
- Forum: threads with nested comments, tabbed answers, or lazy-loaded replies (Reddit, Stack Overflow, Hacker News, GitHub Issues, Discourse).
- SPA / JS-rendered: pages whose raw HTML is a near-empty shell until JavaScript runs, such as public app pages and dashboards. To confirm a page belongs here, view its source rather than the rendered page: if the text you want is missing from the raw HTML, the page is JS-rendered.
Step 2: score five axes
Score each output from 0 to 5 on each axis, for a maximum of 25 per page:
- Cleanliness: no navigation, footer, ads, cookie banners, or sidebar cruft in the output
- Structure: headings keep their levels, lists keep their nesting, blockquotes stay blockquotes
- JS handling: on JS-rendered pages, the actual content comes through rather than an empty shell
- Code blocks: fenced blocks with the right language hint (
```python,```bash,```jsx) rather than plain paragraphs - Tables: tabular content comes out as pipe tables, not flattened text
Score against the page as you see it in your browser, not against another tool's output. Write down a one-line reason for every point you take off: when two tools end up level, the reasons are what tell them apart.
Step 3: fill in one grid per category
For each category, record one row per tool: the five scores, the total out of 25, and your notes. Keep the grids separate rather than adding them into one grand total. A tool that is strong on documentation and weak on forums is a good pick if you mostly convert docs, and a single total would hide that. This table tells you where to look first in each category:
| Category | What it stresses | What to check first |
|---|---|---|
| Documentation | Code samples, parameter tables | A language hint on every fenced block; tables kept as pipe tables |
| News | Ads, newsletters, related stories, captions | Stray copy between paragraphs; captions mixed into the body |
| Wiki | Infoboxes, references, internal links | Infobox handling; references kept as a list; links preserved |
| Forum | Nested or lazy-loaded comments | Comment hierarchy below the first level |
| SPA | Content rendered by JavaScript | Whether any real content comes back at all |
What each type of tool does by construction
Before you score, know what each kind of tool can and cannot do, so a low score on one axis doesn't surprise you:
- Hosted web tools, like MDisBetter URL to Markdown: paste a URL in the browser, convert, download the
.md. MDisBetter works on a free account, each conversion uses credits, and the output is Markdown with YAML front matter, the page's real title, its text and its links converted. There is no API: you paste one URL or a list, one per line, or crawl a site, in the browser. It fetches the HTML without running JavaScript, so expect a low JS-handling score: on an SPA it returns little or nothing and warns you that the page builds its content in JavaScript. - Crawl and extract platforms, like Firecrawl: paid, API-driven, built to crawl whole sites, with depth and wait controls for JS-heavy pages.
- URL-prefix APIs, like Jina Reader: prefix a URL with
r.jina.ai/and get Markdown back from a script. - Scraping and screenshot platforms, like Microlink: paid, with Markdown as one output among several.
- Single-purpose hosted utilities, like MarkdownDown: free, paste a URL, get Markdown.
- Browser extensions, like Browsely: paid, conversion plus an AI sidebar, working inside your own browser tab.
- No-code scrapers, like Simplescraper: paid, built for recurring scrapes, with Markdown export.
- Local libraries: html2text (Python), Trafilatura (Python, built for server-rendered article prose), and Readability (the JavaScript algorithm behind Firefox Reader View). Free and local, but none of them runs JavaScript: on an SPA they only see the empty shell unless you render the page first with a headless browser. html2text also converts whatever HTML you hand it, navigation included, so it needs a cleaning step in front.
Pitfalls that skew a comparison
- Easy pages only: a test set of clean, server-rendered pages makes every tool look alike. Include the awkward pages you actually meet.
- Paywalls and logins: a tool that fetches the page from its own servers only gets what an anonymous visitor sees, usually a teaser plus a paywall message; a browser extension sees what your logged-in browser sees. Don't score a tool down for respecting a paywall: extracting behind one is the user's responsibility, not the tool's.
- Live pages move: run every tool on the same day, and save the raw HTML or a screenshot of each page next to your scores so you can settle disagreements later.
- Grading against a favorite: score against the page itself, not against the output of the tool you already use.
- One grand total: an average across categories hides the category that matters most to you. Read the grids one by one.
- Price and workflow: an API, a browser tool, and a local library don't cost or fit the same way. Note them next to the scores rather than folding them into the scores.
Picking by use case
Once your grids are filled in, match the result to the shape of your work:
One-off URL conversion in the browser, on a free account: MDisBetter.
Scripted scrape of one URL at a time, simple API: Jina Reader.
Full-site crawl with depth control: Firecrawl.
Local batch over server-rendered prose: Trafilatura.
In-browser conversion plus AI chat in the same tab: Browsely.
Pure local with no service dependency: html2text or Readability.
RAG pipeline construction: see the URL-to-Markdown for RAG guide and the runnable RAG tutorial.
For head-to-head positioning, see MDisBetter vs Firecrawl and our Browsely comparison.
What about PDFs in the same workflow?
Many extraction workflows mix web URLs with PDF documents (whitepapers, RFCs, design docs, financial filings). The tools above are URL-only or URL-primary; for the PDF half of the workflow see best free PDF to Markdown converters and the dedicated PDF-to-Markdown tool. The same method applies there: sample your own documents by type and score them on the axes that matter to you.
How often to re-run it
URL to Markdown tools ship changes often, and the pages under them change too. Re-run your grids before you commit to a tool, when you switch tools, and on a regular cadence such as once a quarter if the output feeds something important. Keep the same URLs where they still exist so the results stay comparable. See also our review of the main URL to Markdown tools and 8 URL to Markdown tools and how to compare them.