To Markdown: How I Convert Any Web Page for AI Tools (2026 Guide)

Every time I paste a web page into an AI chat, the same thing happens. Nav bars, cookie banners, "subscribe to our newsletter," three paragraphs of footer links. The model reads all of it. I pay for all of it. And the actual answer gets worse because the signal is buried.

So the job is simple to state: take a page, convert it to Markdown, keep the content, drop the chrome. I have been doing this daily for about a year, mostly to feed docs into Claude and Cursor. Here is what I have learned, including where my own tool loses.

What "to Markdown" actually means in practice

HTML is a layout format. Markdown is a content format. Converting between them means making decisions:

• <h2> becomes ##. Easy.
• A <div> styled to look like a heading? Now you need heuristics.
• Code blocks need language hints preserved, or the model guesses wrong.
• Tables either survive as pipe tables or turn into unreadable mush.
• Navigation, ads, and related-posts widgets should be deleted entirely.

A good converter is mostly a good extractor. The HTML-to-Markdown part is the easy half.

Here is a chunk of a real MDN page after conversion:

## Array.prototype.flat()

The `flat()` method of Array instances creates a new array with
all sub-array elements concatenated into it recursively up to
the specified depth.

### Syntax

\```js
flat()
flat(depth)
\```

### Parameters

- `depth` (Optional)
  - : The depth level specifying how deep a nested array
    structure should be flattened. Defaults to 1.

### Return value

A new array with the sub-array elements concatenated into it.

That is roughly 90 tokens. The raw page HTML was over 40,000 characters. That gap is the whole point.

The options I tested

Jina Reader

Prefix any URL with r.jina.ai/ and you get Markdown back. No install, works from curl, works from a shell script, works on any OS. For public pages it is genuinely excellent and I still use it inside automation scripts.

The limit is structural: it fetches the page from Jina's servers. If a page needs your session, Jina's server does not have it. Internal wikis, a Substack post you pay for, a Notion page behind SSO, your own dashboard - the server sees a login wall or a 403.

Firecrawl

Firecrawl is the serious crawling option. It renders JavaScript, follows links, handles sitemaps, and returns structured output. If your job is "ingest 800 pages of documentation into a RAG index," Firecrawl is the right answer and this post is not. It is an API product: you need a key, and volume costs money.

MarkDownload

A browser extension, open source, and it runs client-side with Mozilla's Readability plus Turndown. That is a sound architecture and it is free. In my testing it is accurate on article-shaped pages. Where I wanted more: no token counting, and no one-click handoff to an AI tool - you get a file or clipboard content, then you do the rest yourself.

Web2MD

This is my extension, so read the rest with that in mind.

It runs entirely in the page you are already looking at. The DOM it converts is the DOM your browser rendered, after login, after JavaScript, after any paywall you legitimately have access to. Nothing is fetched server-side because nothing needs to be.

The logged-in page test

This is the test that separates the approaches, so I ran it deliberately.

I took a paid Substack post I subscribe to. Through a server-side reader, I got the public preview - two paragraphs and a subscribe button. Through the extension, I got the full post, because my browser was already authenticated and the content was already on screen.

Same result pattern on a company Notion wiki and on a GitHub private repo README. The page renders for me; the converter sees what I see.

# Q3 Infrastructure Review

**Status:** Draft | **Owner:** Platform team

## Summary

We cut p99 latency on the ingest path from 840ms to 190ms by
moving batch flush off the request thread.

| Metric      | Before | After |
|-------------|--------|-------|
| p50         | 42ms   | 38ms  |
| p99         | 840ms  | 190ms |
| Error rate  | 0.4%   | 0.1%  |

## What did not work

Increasing the connection pool. We tried 200 connections and
saw no improvement, which pointed at the flush, not the pool.

Note the table survived as a pipe table. That matters more than it sounds - models reason noticeably better over a pipe table than over a table flattened into prose.

Honest limits

I would rather you find these out here than after installing.

• Chrome only. Chromium-based browsers work (Edge, Brave, Arc). No Firefox, no Safari. If you are on Firefox, MarkDownload is your answer and it is a good one.
• Free tier is 3 conversions per day. That is enough to evaluate it and enough for light use. It is not enough for a research session.
• Pro is $9 per month for unlimited conversions. If that is not worth it for your usage, the free tier stays free and the honest advice is to use Jina Reader on public pages.
• No crawling. One page at a time, the page you are on. If you need to convert 500 URLs, use Firecrawl.
• Hard pages stay hard. Canvas-rendered content, heavy single-page apps that render text into non-semantic divs, and PDF viewers all produce weaker output. Nothing client-side fixes those.

The token counter

The feature I use most is also the least flashy. Before you copy anything, you see the token count.

It changed my behavior. A docs page I assumed was "small" turned out to be 14,000 tokens. A changelog I almost pasted whole was 31,000. Seeing the number before the paste means I trim first, or split into two prompts, instead of discovering the problem when a context window fills up mid-task. If you work with a 200k window, a few of these pastes is most of your budget.

Related reading if you are optimizing prompts: our notes on counting tokens before you paste and converting web pages for ChatGPT.

Privacy, concretely

Server-side converters fetch the URL. That means the operator's logs contain the URL you read. If the page is an internal doc, you have also handed them a path they could try to reach.

Client-side conversion sends neither. The HTML is already in your browser; the conversion is JavaScript running on that HTML; the Markdown lands in your clipboard. For work pages, that distinction is usually the whole decision, regardless of which extension you pick.

How I actually choose

• Public page, one-off, any browser: Jina Reader. Fastest path, zero install.
• Bulk crawl into an index: Firecrawl. It is built for that.
• Firefox or Safari, article pages: MarkDownload.
• Logged-in, paywalled, or internal pages, and I want the token count before pasting: Web2MD.

These overlap less than the marketing of any of them suggests. I have all four available and reach for different ones in a given week.

If you want to try it

Web2MD is free for 3 conversions a day, no account and no API key - install it, open a page you could not convert before, and see whether the output is actually usable for your workflow. If it is not, one of the other three above probably is, and that is a fine outcome too.