Turn a URL into markdown

How it works

1. We load the page in a real headless Chromium and wait for scripts, fonts, and images within configured limits, so what gets extracted is what a reader saw.
2. The extraction walks the rendered document and keeps the reading structure: headings, paragraphs, lists, tables, links and image references.
3. The markdown is shown right here, with a copy button; nothing is stored beyond the normal retention window.

Built for pipelines, not just reading

This is the same extraction the API returns as its markdown format, which is the format people reach for when a model, a search index, or a notes pipeline needs a page's content without its chrome. Stable heading hierarchy, absolute links, no script or style residue. The field-level behaviour (what each option changes, what the errors mean) is documented in the convert body fields, and a worked program that calls it from TypeScript lives in the markdown recipe.

Who uses this

Engineers feeding documentation into RAG pipelines, analysts moving articles into a corpus, and anyone migrating a reading list out of browser tabs. When one extraction becomes part of a job, the curl shown after a successful run is the exact API calls, and a free key does 50 renders a month.

The limits that actually bite

Public http(s) pages only; private and local addresses are refused. A page with almost no readable text is refused as thin content rather than answered with an empty file. Very large extractions are offered as a download instead of inline text. The anonymous allowance is a few runs per minute and ten per day per address, one shared pool across every tool on this site.

Questions

What does the extraction keep, and what does it drop?

You get the document's reading structure: headings, paragraphs, lists, tables, links and image references, as markdown. Navigation chrome, scripts, styles and ad slots do not survive extraction, which is exactly the point: what is left is the content, ready for a model or a notes pipeline.

Why was my URL refused for thin content?

Pages whose readable text is under a few characters (some image-only landing pages, for instance) are refused rather than answered with an empty file. The error says what was detected so you can tell a genuine empty page from a rendering failure.

Is the result suitable for RAG and LLM context?

That is what it is built for: stable heading hierarchy, absolute links, no boilerplate. The same extraction backs the API's markdown format, so anything you see here is what a keyed call returns, minus the rate limits.

How big can the result be?

Very large extractions are shown as a size with a download link instead of inline text, so the page never falls over on a huge document; the download is the same markdown either way.