Convert Any Web Page URL to Markdown
Processing happens 100% in your browser — nothing is uploaded.
Only what an anonymous visitor can see
How to convert a web page URL to Markdown
- Input: paste the full URL, including the https:// scheme, into the field.
- Process: the page is fetched anonymously, Readability isolates the article in your browser, and Turndown renders GitHub-flavoured Markdown locally.
- Copy: send the Markdown to your clipboard or save it as a .md file.
Why Convert URL to Markdown with MD Convert?
Readability extraction, not a full-page dump
Candidate containers are scored on link density, paragraph ratio, and boilerplate class names, so navigation bars, cookie banners, ad slots, share rails, and comment threads lose to the article body. You get prose with its headings, lists, links, and code blocks intact.
Parsing is 100% local to your browser
The DOM is built by your own browser, Readability scores it in your tab, and Turndown renders the Markdown in your tab. No page content is processed, stored, or logged on any MD Convert server.
Stateless same-origin fetch, zero retention
Browsers block cross-origin reads from page JavaScript, so a same-origin Function requests the public page anonymously and streams the HTML straight back. It has no database, no cache, and no request log — there is nothing to retain and no session of yours attached.
Output shaped for LLM and RAG pipelines
Stripping boilerplate cuts token count sharply against raw HTML for the same prose, and the surviving heading hierarchy gives a chunker real semantic split points instead of arbitrary token windows.
URL to Markdown: Before and After
A typical article page. Everything outside the scored article subtree — the nav, the consent banner, the inline script — is discarded before Turndown ever sees the markup.
<body>
<nav class="site-nav"><a href="/">Home</a><a href="/blog">Blog</a></nav>
<div id="cookie-consent">We value your privacy…<button>Accept</button></div>
<article>
<h1>Streaming Parsers in the Browser</h1>
<p>Parsing a large file in a tab used to mean
<a href="/blog/workers">freezing the main thread</a>.</p>
<h2>Why workers matter</h2>
<ul><li>Constant peak memory</li><li>Responsive UI</li></ul>
<pre><code class="language-js">await worker.postMessage(file);</code></pre>
</article>
<aside class="promo">Subscribe to our newsletter!</aside>
<script>trackPageview();</script>
</body># Streaming Parsers in the Browser
Parsing a large file in a tab used to mean [freezing the main thread](https://example.com/blog/workers).
## Why workers matter
- Constant peak memory
- Responsive UI
```js
await worker.postMessage(file);
```Understanding the URL Format: WHATWG HTML Living Standard
- Format
- HTML document retrieved over HTTP
- Specification
- WHATWG HTML Living Standard
- Media type
text/html- Parser used
- Mozilla Readability + Turndown
A modern article page is mostly not the article. Between the opening tag and the closing one sit a sticky header, a mega-menu, a cookie consent dialogue, two or three ad slots, a newsletter interstitial, a social share rail, an author bio card, a related-posts grid, a comment thread and a footer with sixty links in it. The prose you actually came for is frequently under fifteen percent of the delivered bytes. Converting the raw document to Markdown gives you all of that furniture rendered as a wall of link lists, which is worse than useless — it is expensive noise that pollutes a note, a diff or an embedding.
Extraction is therefore the whole job, and it is a scoring problem rather than a parsing problem. Mozilla Readability, the engine behind Firefox Reader View, walks the parsed DOM and assigns each candidate container a score built from the things that empirically distinguish body copy from chrome: the number of commas in its text, the density of links relative to text length, the ratio of paragraph elements to other children, and penalties for class and id names matching known boilerplate patterns. The highest-scoring subtree wins and becomes the article; its siblings are discarded.
Once the article subtree is isolated, it is a small, clean fragment of semantic HTML — headings, paragraphs, lists, blockquotes, figures, code blocks and inline links. Turndown then maps that fragment to GitHub-Flavored Markdown using the same rule set every other converter on this site shares, so a heading from a web page and a heading from a DOCX come out byte-identical. The page title is emitted as a level-one heading above the body, which is what note-taking tools and chunkers both expect to find first.
What the fetch actually does, and what it does not
Browsers refuse to let page JavaScript read the response body of an arbitrary cross-origin request. That is the same-origin policy, and it is not a bug to be worked around casually: it is what stops any site you visit from silently reading your webmail. A converter that runs in a tab therefore cannot simply fetch the URL you paste, because the target site will not send the permissive access-control header that would authorise it.
The retrieval hop is handled by a same-origin Function on this site's own domain, which requests the page as an anonymous visitor and streams the HTML straight back to your tab. It is stateless by construction: it holds no database, writes no log of requested URLs, sets no cookie, and keeps no cache, so there is nothing to retain and nothing to leak. It also carries none of your session — no cookies, no authorisation header, no stored credential — which is precisely why it cannot reach anything behind a login.
Everything after that byte stream is local. The DOM is built by your browser's own parser, Readability scores it in your tab, Turndown renders the Markdown in your tab, and the result is handed to the clipboard or a blob download without a second network call. The honest summary is narrow and worth stating plainly: one anonymous fetch of a publicly reachable document, then a hundred percent local processing with zero storage on either side.
Why client-rendered pages come back thin or empty
The fetch retrieves the HTML the server sends. It does not run scripts. For a server-rendered page that is the entire document, but for an application that ships an empty root element and paints its content from a client-side framework, the delivered HTML contains a shell and a bundle reference — and no prose at all. Readability scores that shell, finds no candidate worth returning, and the converter reports that it could not extract readable content.
The diagnostic takes five seconds: open the URL, use View Source rather than the element inspector, and search for a sentence you can see on screen. View Source shows the bytes the server sent; the inspector shows the live DOM after scripts have mutated it. If your sentence is present in the inspector but absent from the source, no fetch-based converter of any kind will find it, because the text is manufactured after delivery. Copying the rendered article into the HTML converter is the reliable route in that case.
The same reasoning explains the other common failures. Paywalled articles are served as a teaser plus a subscription wall to anonymous requests, so a teaser is what comes back. Pages behind single sign-on return a login form. Sites fronted by aggressive bot mitigation may answer with a challenge page instead of the article. In each case the converter is faithfully reporting what the origin chose to send an unauthenticated visitor.
Shaping web pages for retrieval and chunking
For a retrieval pipeline, boilerplate is not merely untidy — it is measurably harmful. A chunker splitting on a fixed token window will produce fragments made entirely of navigation links, and those fragments get embedded and indexed alongside real content, where they compete for nearest-neighbour slots and return matches with no answer in them. Cookie-banner text is especially damaging because it is near-identical across thousands of pages, which is exactly the profile of a vector that matches everything and means nothing.
Extracted Markdown fixes this structurally rather than statistically. The heading hierarchy that survives extraction gives a splitter honest semantic boundaries: split on level-two headings and each chunk is a self-contained section rather than an arbitrary token slice. Because the output carries no markup attributes, no inline styles and no scripts, the token count drops sharply against raw HTML for the same prose — often by an order of magnitude on a heavily templated page — which is a direct reduction in embedding and context cost.
The stable-format argument matters too. Markdown is what instruction-tuned models were trained to read structure from, so a fenced code block or a pipe table is interpreted as a code block or a table rather than reconstructed from angle brackets. Keeping ingested sources in one canonical Markdown shape, whether they arrived as a URL, a PDF or a notebook, means one chunker and one prompt template instead of a special case per source type.
Links, images and the things Markdown cannot hold
A base element carrying the source URL is injected before extraction runs, so relative references resolve against the original document. A link written as a root-relative path in the source becomes a fully qualified absolute URL in the output, which is what makes the Markdown portable — pasted into a note or a repository, every link still resolves instead of dangling against your own domain.
Images are emitted as standard Markdown image syntax pointing at their original absolute locations. They are references, not copies: nothing is downloaded and nothing is inlined, so the file stays small and the images load from the origin. That is the right default for a note, and a real constraint for an archive, because a hotlinked image dies when the source reorganises its media paths. If permanence matters, save the assets separately and rewrite the paths.
Some things have no Markdown representation and are dropped rather than faked. Embedded players, interactive widgets and framed content disappear, since a container element with no text carries nothing convertible. Multi-column layouts, pull quotes positioned by stylesheet, and anything whose meaning lives in its CSS flatten into linear document order. This is the correct trade: Markdown is a semantic format, and information encoded purely in presentation is not semantic.
Known limitations of URL to Markdown conversion
Being explicit about what a converter cannot do saves you a wasted upload. These are the boundaries of what is recoverable from URL programmatically:
- Pages requiring authentication, a subscription or a paywall bypass return whatever an anonymous visitor sees — typically a login form or a teaser.
- Client-rendered applications that paint their content with JavaScript deliver an empty shell; no scripts are executed during retrieval.
- Sites behind bot-mitigation challenges may answer the fetch with the challenge page rather than the article.
- Extraction is heuristic. Unconventional layouts, listing pages and documents with several equally-weighted content blocks can lose a section or keep a sidebar.
- Images are linked at their original URLs, never downloaded, so the Markdown breaks if the source moves its assets.
- Embedded players, framed content and interactive widgets are dropped — Markdown has no equivalent element.
- One URL per conversion. There is no crawler and no queue, by design.
- The retrieval hop is a request from a server, not from your device, so it is not a fully offline operation the way the file-based converters are.
Who Converts URL to Markdown?
Retrieval pipeline engineers
Turning documentation and reference pages into clean, chunkable Markdown before embedding, without paying token cost for navigation menus and cookie banners.
Researchers & analysts
Archiving the readable text of a source into a permanent note, so the citation survives the page being redesigned, paywalled or deleted.
Technical writers
Pulling a published article back into Markdown to revise it in a repository, rather than fighting a rich-text editor to recover the original structure.
Knowledge-base owners
Importing external references into Obsidian, Logseq or a docs site as plain Markdown files that grep, diff and sync like any other note.
URL to Markdown: Comparing the Practical Approaches
| Method | Boilerplate removal | Client-rendered pages | Data retention | Setup | Batch / automation | Cost |
|---|---|---|---|---|---|---|
| This tool (Readability + Turndown) | Strong — article subtree is scored and isolated | Not supported (no script execution) | None — stateless fetch, local parse, no logs | None — paste a URL | One page at a time | Free |
| curl piped into Pandoc | None — you get the whole document, nav included | Not supported | Fully local retrieval and conversion | Local install plus dependencies | Strong — scriptable | Free |
| Headless browser (Playwright, Puppeteer) | Whatever extractor you bolt on yourself | Yes — scripts run before extraction | Yours to define; you own the stack | Heavy — browser binaries and code | Strong, resource-hungry | Infrastructure cost |
| Hosted reader and scraping APIs | Good — extraction is the product | Usually yes | Provider logs the URLs you submit | API key | Strong — built for pipelines | Per-request above a free tier |
| Pasting a page into a chat model | Variable — the model rewrites as it summarises | Not applicable, you supply the text | Prompt is retained under provider policy | None | Poor | Per-token |
How You Can Verify the Privacy Claim
Zero server upload
Conversion runs inside your browser tab. Open DevTools, switch to the Network panel, and convert a file: for every format except URL to Markdown you will see no request carrying your document — because there is no endpoint to send it to.
Off the main thread
Heavy parsing is dispatched to a Web Worker, so a 500-page PDF or a large spreadsheet never freezes the interface. Everything is plain JavaScript — no native plugin, no WebAssembly toolchain, nothing to install.
Nothing to sign up for
No login, no quota, no paywall, and no tracking tied to your files. Analytics are cookieless and aggregate only. Read the privacy policy for the full data-flow breakdown, including the one proxied exception.
The parsers doing the work
No proprietary black box: each format is handled by a widely audited open-source library, running client-side at the version pinned in our lockfile.
URL to Markdown — FAQ
Why does a JavaScript-rendered page return nothing?
The fetch retrieves the HTML the server sends and never executes scripts. An app that paints its content client-side delivers only a shell, so there is no prose for Readability to score. Check with View Source rather than the element inspector: if your text is missing there, it is generated after delivery.
Is the fetched page content stored or logged anywhere?
No. The same-origin Function streams the HTML to your browser and keeps nothing — no cache, no database, no URL log. All parsing happens in your tab, and the Markdown is never sent anywhere.
Does it work on paywalled or login-protected pages?
No. The request is anonymous and carries none of your cookies or credentials, so you get whatever an unauthenticated visitor gets: a teaser, a subscription wall, or a login form.
Is the output clean enough for a RAG or LLM pipeline?
That is the primary use case. Boilerplate is removed before conversion, so embeddings are not polluted by near-identical cookie-banner and navigation chunks, and the heading hierarchy survives as natural chunk boundaries. Splitting on level-two headings yields self-contained sections.
Do links and images work when pasted into Obsidian?
Yes. A base URL is injected before extraction, so relative links and image sources resolve to absolute URLs and keep working in any vault or repository. Images are referenced at their original locations, never downloaded, so archive them separately if permanence matters.