Jina Reader vs Spider Cloud in 2026: one URL vs a whole site

Jina Reader is for anyone who needs one page as clean text right now, with no SDK, no key for the first few calls, and nothing to configure. It is the fastest path from a URL to something you can paste into a prompt. Spider Cloud is a research lab for web data quality. Our product is a crawler behind an API, and what we measure ourselves on is whether the pages you get back are complete and correct across a whole site, including the pages that push back. Speed and cost are the evidence.

The verdict. These two overlap on exactly one task, fetching a single page as markdown, and there Jina Reader is hard to beat for a prototype or a one-off. Once the job is a site rather than a page, or the targets sit behind bot protection, or you need the browser to do something before you read, Spider is the tool, and its bill tracks what you used. Many teams run both, Reader in the notebook and Spider in production. The compare page covers the wider field.

Side by side

How Jina Reader is used

The whole interface is a URL prefix.

https://r.jina.ai/https://spider.cloud/docs/

That returns the page as markdown. Pass Accept: application/json and you get url, title, content and timestamp fields instead. The X-Return-Format header switches formats, and X-Respond-With: readerlm-v2 runs the page through Jina’s ReaderLM-v2 model for the conversion. Search is the same idea on a different host:

https://s.jina.ai/spider%20cloud%20pricing

In code it is one GET:

import os, requests

url = "https://spider.cloud/docs/"
resp = requests.get(
    f"https://r.jina.ai/{url}",
    headers={
        "Authorization": f"Bearer {os.getenv('JINA_API_KEY')}",
        "Accept": "application/json",
    },
)
data = resp.json()["data"]
print(data["title"], len(data["content"]))

Rate limits, from the Reader page as of September 2026: r.jina.ai allows 20 requests a minute with no key, 500 a minute on a free or paid key, and 5,000 a minute on premium. s.jina.ai is blocked without a key, allows 100 a minute on free and paid keys, and 1,000 a minute on premium.

What changes when one page becomes a thousand

The prefix API is built around one request per page, and that shapes everything downstream. To read a 1,000-page docs site through Reader you write the crawler yourself: a queue of URLs, a set of the ones you have seen, a rule for how deep to follow links, and a retry policy for the calls that fail. None of that is hard, but all of it is code you now own, and it is the part that breaks when the site restructures.

The rate limits set the floor on wall-clock time. At 500 requests a minute on a paid key, 1,000 pages is at least two minutes and 100,000 pages is at least three and a half hours, on one key, before any retries. Spider accounts get 10,000 requests a minute by default, and a single /crawl call handles the queue, deduplication and depth for you, so a 1,000-page site is one request and the pages arrive as a stream while the crawl is still running.

Billing changes shape too. Reader charges per output token, so a site with long pages costs more than a site with short ones and you find out afterward. Spider charges per byte and per CPU minute, and the crawl endpoint accepts a limit and a depth so the ceiling on a run is set before it starts.

Jina Reader pricing

Jina prices by token. One key covers Reader, Embeddings and Reranker, every new key comes with 10 million free tokens, and Reader bills the output tokens in the response. Search is billed as a fixed block of tokens per request, starting at 10,000. There are no monthly plans; you buy tokens up front.

The per-million-token rate is the number we could not pin down. A Jina blog post quotes $0.02 per million tokens, an older one from January 2025 lists prepaid packages of $50 for 1 billion tokens and $500 for 11 billion, and the API dashboard showed no price when we checked. Rather than print a figure that may be stale, we will point you at the Reader page for the rate in force. Jina also publishes no guidance on how many tokens a typical page produces, so a per-page cost is something you estimate from your own corpus. A long article can be tens of thousands of output tokens; a product page a few hundred.

That token model suits light, predictable use. It is harder to budget when page sizes vary by two orders of magnitude, and a 500 request per minute ceiling on paid keys caps any single key at roughly 21 million requests a month even if you wanted to push it.

Spider bills $1 per GB transferred and $0.001 per CPU minute, and nothing else. Rendering rolls into compute, standard proxy rotation is included, and a request that fails costs $0. 100,000 pages in smart mode is about $8 to $15; 10,000 pages in HTTP mode about $0.80 to $1.00; a million pages in chrome mode with markdown and metadata about $80 to $160. Page size moves the bandwidth line, but you can read the estimate off the pricing guide before you run anything, and credits never expire. A fixed bill is available too through Unlimited, from $40 a month.

What we could not verify

Jina publishes no crawl benchmark and neither do we for Reader, so there is no success rate to compare here. We did not measure Reader on the 1,000-URL corpus from our crawl benchmark, because it has no crawl endpoint and the comparison would be unfair in both directions. Spider’s 99.9% on that corpus is our own number and not independently verified, and it belongs to the Firecrawl and Crawl4AI comparisons rather than this one.

We also could not confirm, from Jina’s pages, a Reader MCP server, a self-hosting guide, or the license on the current reader repository. The repo exists on GitHub; read the license file yourself before building on it.

Where Jina Reader wins

Zero friction. No SDK, no account for the first 20 requests a minute, no request body. A URL in a browser tab is a working demo.

Quick single-page reads at runtime. An app that pulls one page into a prompt on demand gets the smallest possible integration, and 10 million free tokens covers a lot of ad hoc reading before a card is needed.

Search and read in one family. s.jina.ai plus r.jina.ai is a lightweight research loop without setting up a crawl, and ReaderLM-v2 is a purpose-built HTML-to-markdown model you can switch on with a header.

Where Spider wins

Whole sites. Give /crawl a starting URL and a limit, and Spider follows links, deduplicates, controls depth, renders where needed and returns every page in one response or as a JSONL stream. Reader is one URL per call, so 500 pages of docs means 500 calls plus your own queue, frontier and deduplication code.

Protected pages. Reader’s page does not document proxy pools or an unblocking mode, so a page that challenges the fetcher comes back as whatever the site served. Spider’s infrastructure carries residential and ISP proxy pools across 199+ countries, a stealth mode, and an unblocker endpoint for sites behind common bot-protection services.

Smart rendering. Smart mode fetches static pages over plain HTTP and opens a browser only when the page needs one, which is where much of the speed and cost difference at volume comes from.

A browser you can drive. Spider Browser is a live session with extract, act, observe and agent methods on the DOM after clicks and scripts have run. Reader fetches and converts; it does not log in, paginate or expand anything.

import { SpiderBrowser } from "spider-browser";

const spider = new SpiderBrowser({
  apiKey: process.env.SPIDER_API_KEY,
});

await spider.init();
await spider.page.goto("https://spider.cloud/pricing/");
await spider.page.waitForSelector("table");

const plans = await spider.page.extract(
  "List every plan with its price and what it includes"
);
console.log(plans);
await spider.close();

Formats. One return_format parameter gives markdown, commonmark, text, XML, raw HTML or bytes, and responses come back as JSON, JSONL, CSV or XML.

Migration: one page, then a site

The single-page task in both.

Jina Reader

import os, requests

resp = requests.get(
    "https://r.jina.ai/https://spider.cloud/docs/",
    headers={"Authorization": f"Bearer {os.getenv('JINA_API_KEY')}"},
)
print(resp.text[:500])

Spider

from spider import Spider
import os

client = Spider(api_key=os.getenv("SPIDER_API_KEY"))

pages = client.scrape_url(
    "https://spider.cloud/docs/",
    params={"return_format": "markdown", "request": "smart"},
)
print(pages[0]["content"][:500])

And the site-wide task, which only one of them has an endpoint for.

pages = client.crawl_url(
    "https://spider.cloud/docs/",
    params={
        "limit": 500,
        "return_format": "markdown",
        "request": "smart",
    },
)

for page in pages:
    print(f"{page['url']}: {len(page.get('content', ''))} chars")

Parameters for limits, depth, formats and streaming are on the crawl endpoint docs; the single-page call is on the scrape endpoint docs.

When to pick which

Pick Jina Reader for one-off fetches, prompt augmentation at runtime, a search-then-read loop in a prototype, or any light workload that fits inside the free tokens. Pick it when the integration has to be a single GET and nothing more.

Pick Spider when the job is a site, when targets include protected pages, when the pipeline is continuous ingestion where completeness matters, or when the browser has to do something before you can read. For the managed crawlers that compete with Spider on the site-wide job, see Spider vs Firecrawl and, for the self-hosted case, Spider vs Crawl4AI. The best Firecrawl alternatives roundup covers Reader alongside the rest.

The overlap is one page, so test it on one page. Take a URL you need, fetch it through r.jina.ai, then run the same URL through the playground and compare the two outputs side by side.