Jina Reader Alternatives: URL to Markdown APIs and the DIY Route

Firecrawl, ScrapingBee, ZenRows and ScraperAPI compared with Jina Reader on Markdown output, billing and failed pages, plus a DIY fetcher through proxies.

Jina Reader made URL to Markdown a one-line job: it converts a URL to LLM-friendly text when you prepend r.jina.ai to it. That interface makes it a common first choice for retrieval prototypes. When a prototype becomes a pipeline, cost per page, rate limits and blocked sources start to matter, and that is the point to compare it with other options. The alternatives fall into two groups. Other hosted APIs return Markdown from a URL too: Firecrawl, ScrapingBee, ZenRows and ScraperAPI. The second group is doing the step yourself, with your own fetcher, a proxy for the network side and an open-source converter. This page compares the hosted options on outputs, billing unit and what happens when a page fails, then shows the do-it-yourself version in about twenty lines of Python.

Vendor figures were checked October 19, 2026, on each vendor's own pricing page or documentation. No service was benchmarked for this page, so nothing here ranks the quality of anyone's Markdown. For Jina, that meant three sources that describe different parts of the product: the Reader page, the hosted API reference and the official open-source repository. Where they disagree, this page says so. No Reader request was sent to test any of them.

What Jina Reader does

Reader takes a public URL and returns the main content as Markdown, with navigation, footers and ads stripped. It has an X-Engine header that picks a plain HTTP fetch or a headless browser, which runs the page's JavaScript before extraction, though Jina's landing page, hosted API reference and open-source README disagree on which engine is the default. It also has native PDF reading and generated captions for images that lack alt text. Requests that repeat are cheap to serve: Reader returns cached content for a URL requested again within 5 minutes, and the same page documents headers that ask for a fresher copy.

Markdown is the default, not the only output. The hosted reference documents an X-Respond-With header whose documented formats include markdown, html, text, screenshot and pageshot. The repository README describes html as the page's full markup (its documentElement.outerHTML), screenshot as a link to a capture of the viewport and pageshot as an attempt at the whole page. The Reader page itself does not list these formats in its text, which is why they are easy to miss. The repository is the open-source branch of the hosted code, so it is good evidence of what the interface offers, but it does not certify hosted limits, pricing or output quality for these formats. Test them on your own URLs.

Pricing has two layers. There is free basic use without an API key, at 20 requests a minute. With a key, Reader is billed in tokens, counted on the output response, and Jina gives 10M free tokens with every new API key. The billing policy also says no tokens deducted for failed requests.

Why teams look for a Jina Reader alternative

Most of the reasons come from moving off a handful of URLs and onto thousands a day.

• Cost follows page length, not page count. Because tokens are counted on the output, a long documentation page costs more than a short product page. That is fair, but it makes a monthly budget hard to set until you know the average length of your sources.
• Rate limits shape the crawl. Reader's rate-limit table lists 500 requests a minute on a paid key and 5,000 on a premium key, though the FAQ on the same page lists different per-key limits for the free tier. A backfill of a large document set has to be scheduled around that ceiling.
• Blocked sources may stay blocked. The Reader page says Reader does not try to get past a site's bot defenses; a blocked request stays blocked, on any key tier, though Jina's open-source README describes an optional hosted proxy, for keyed requests, that handles common anti-bot challenges. If a site you depend on refuses Reader, test it with and without that option before assuming either answer.
• Other outputs need testing, not a second tool by default. If you also need a visual capture or the full markup for your own parser, check the html, screenshot and pageshot formats on your URLs before adding another service. What they return, how long a screenshot link lasts and what each costs in tokens is not stated on the Reader page.
• Running it yourself. Reader's service code is published on Jina AI's GitHub organization, separately from the model license: the README states the code is Apache-2.0. The models are a different matter: Reader's models are licensed CC-BY-NC 4.0, so commercial use of the weights needs a separate license, which matters if the plan was to move the whole step in-house with those models.

None of these makes Reader a poor choice. They are the questions to answer before choosing what replaces it, or what runs beside it.

URL to Markdown options side by side

The first five rows are hosted APIs. The last row is a different kind of setup, included because at volume it is the main alternative to paying per page or per token.

On ScraperAPI, the credit weights in the table are per parameter, and some domains carry their own credit cost, such as Google and Bing at 25 credits a request.

Read the last column carefully, because "billed only for successful requests" means different things on different pages. Firecrawl bills a 403 page; ScraperAPI bills a 404; ZenRows counts a 404 as a result; ScrapingBee's default turns most target errors into its own 500, which it does not bill. If your sources include many dead or refusing URLs, that column moves your cost more than the plan price does.

What to test before you switch

A short trial on your own URLs tells you more than any comparison table, this one included.

1. Take fifty URLs from your real source list and include the awkward ones: a page that renders client-side, a long table, a docs page with code blocks, a PDF and a URL that now returns 404.
2. Send each URL through every candidate and save the output to a file named after the URL and the service.
3. Open the files side by side. Check that headings keep their levels, tables stay tables, code blocks keep their fences, relative links became absolute, and cookie banners and navigation are gone.
4. Count the empty or near-empty results, and search the outputs for block-page phrases such as "access denied" or "verify you are human". A service that bills those pages costs more than its plan suggests.
5. Divide what the trial cost by the number of usable documents, not by the number of requests. That is the figure to compare.
6. Repeat a few URLs the next day to see whether you got a fresh copy or a cached one, which matters if you track changes.

The DIY route: your fetcher, a proxy and an open-source converter

If most of your sources are ordinary server-rendered pages, the conversion step is small enough to own. The sketch below fetches through Node4's Rotating Datacenter gateway and converts the main content with trafilatura, an open-source extraction library. Install it with pip install requests trafilatura. The Python guide to turning a web page into Markdown for an LLM builds the full pipeline, with cleanup and chunking for RAG.

import os
import requests
import trafilatura

PROXY = (
    "http://" + os.environ["NODE4_USER"] + ":" + os.environ["NODE4_PASS"]
    + "@gw-rotating_datacenter.node4.io:8083"
)

def url_to_markdown(url: str) -> str:
    resp = requests.get(
        url,
        proxies={"http": PROXY, "https": PROXY},
        headers={"User-Agent": "Mozilla/5.0 (compatible; docs-ingest/1.0)"},
        timeout=30,
    )
    resp.raise_for_status()
    md = trafilatura.extract(
        resp.text,
        url=url,
        output_format="markdown",
        include_links=True,
        include_tables=True,
    )
    if not md or len(md.split()) < 50:
        raise ValueError(f"{url}: little or no main content (JavaScript shell or block page?)")
    return md

if __name__ == "__main__":
    print(url_to_markdown("https://docs.example.org/getting-started"))

The length check at the end is the part people skip. A fetch can return 200 with a page that never rendered or a challenge page, and a converter will happily turn either into short, confident Markdown. Treat "too little text" as a failure and retry or route it differently.

For pages that only render in a browser, swap requests for Playwright and hand its page.content() to the same converter; the Puppeteer and Playwright proxy guide covers the proxy settings, and the Puppeteer rotating proxy article covers one exit per browser or per context.

What Node4 supplies here is the network side only. The rotating gateway picks an exit for each connection from address blocks Node4 owns in the US, Italy and Spain, and a session id in the username holds one exit for up to 30 minutes when a multi-page flow needs it. Sites that refuse datacenter addresses are the case for residential proxies, billed per GB at $7.47/month for 3 GB ($2.49/GB) on the entry plan. Node4 adds no rendering, extraction or retry logic; that stays in your code. The gateway products need a paid plan to test, since free accounts get static shared proxies over HTTP(S) only. Keep the crawl inside each site's rules: the web scraping best practices cover rate, robots.txt and the failures that look like success.

The decision

Stay with Jina Reader if a URL-in, Markdown-out call with token billing fits your volume and your sources accept it. If you need HTML or screenshots as well, test Reader's documented formats before you leave. Move to Firecrawl when you want crawling and several output formats from one service, to ScrapingBee or ZenRows when you want their screenshot options and rendering controls and their credit weights suit your mix of pages, and to ScraperAPI if its per-domain costs work out for your targets. Build the step yourself when most pages are server-rendered and the volume is high and steady, because then you pay for exits rather than for each page. The ScrapingBee alternatives and Firecrawl alternatives guides work through the credit arithmetic, and the ZenRows alternatives guide covers the API-or-proxies split in more depth.

A URL to Markdown API from Node4, in development

Node4 is building a Scrape API that will take a public URL and return rendered HTML, Markdown or a screenshot. It is not available yet, and it has no published price or launch date. The waitlist is open if you want to hear when it opens. Until then, the proxy route above is the Node4 product you can buy and use today.