Jina AI API Review: Pricing & Comparison

Why Jina AI is worth a serious look

Jina AI doesn’t do chat completion, and it isn’t trying to compete with OpenAI or Anthropic there. The more useful claim is narrower and more concrete: Embeddings, Reranker, and Reader (its URL-to-clean-text scraper) all run on the same API key and draw from the same token pool — sign up and every new key comes with 10M free tokens, no credit card required, usable across all three products. That combination is genuinely uncommon. Most competitors sell you a single layer of the retrieval stack — Voyage AI does embeddings only, Cohere pairs embeddings with reranking but ships no scraper — and leave you to wire the rest together yourself.

Three things back that up:

• Reader’s convention is close to zero-friction. Put a URL after https://r.jina.ai/, send a GET request, and Markdown comes back — no SDK, no request body, and (the tutorial below tests this live) it even works without an API key.
• Late Chunking and Matryoshka embeddings are real, usable features, not spec-sheet checkboxes — covered in detail after the tutorial gives you something concrete to hang them on.
• The free tier is generous enough to actually build something with. 10M tokens shared across three products is enough to prototype a full retrieval pipeline before you spend anything.

None of that erases what Jina AI can’t do: it has no LLM of its own, so generation is always someone else’s job, and — covered honestly near the end of this review — mainland China access needs a proxy. But the rest of this page leads with the how-to, because that’s where most of the actual value shows up.

Currently available models

Model	Type	Context length	Notes
jina-embeddings-v4	Embedding	32K tokens	3.8B parameters, multimodal text + image + PDF
jina-embeddings-v5-text	Embedding	32K tokens	Two sizes — 677M (small) / 239M (nano) — with task-specific LoRA
jina-embeddings-v5-omni	Embedding	32K tokens	Multimodal: text, image, audio, and video share one vector space with v5-text
jina-embeddings-v3	Embedding	8K tokens	89 languages, the most production-tested version
jina-reranker-v3	Reranking	131K tokens	BEIR nDCG@10=61.94, 100+ languages
jina-reranker-m0	Reranking	—	Multimodal: reranks image+text query/document pairs
jina-reranker-v2-base-multilingual	Reranking	1K tokens (auto-chunked)	A value option, multilingual
jina-reader	Content extraction	—	URL → Markdown/JSON, supports PDF

Two things the table doesn’t show. First, v4 embeds text, images, and PDFs into the same vector space — pass in a product photo and a caption, and you get two directly-comparable vectors — but image billing is granular: every 28×28-pixel tile costs 10 tokens, so embedding a batch of large images can burn through your free tokens fast. Second, v3 is still the safest default if you don’t need multimodal input: 8K context, 89 languages, and the longest production track record of the lineup.

Free tier and rate limits: 10M tokens, no credit card

New keys get 10M tokens of free credit, no credit card required, shared across Embeddings, Reranker, and Reader — burn through it fast on a batch embeddings job and Reader/Reranker calls draw from the same depleted pool.

Tier	RPM	TPM (embeddings)	Concurrent requests
Anonymous (Reader only, no key)	20	—	—
Free API key	100	100K	2
Paid	500	2M	50
Premium (enterprise)	5,000	50M	500

Reader’s free-key tier gets 500 RPM — noticeably more generous than the Embeddings/Reranker free tier’s 100 RPM — which fits its typical use case of bulk-crawling a lot of pages quickly.

Hands-on tutorial: ingest a page, embed it, rerank a query against it

Jina doesn’t maintain an official heavyweight Python/Node SDK for these three APIs — the documented (and, in practice, the recommended) path is calling the REST endpoints directly, which is exactly what every example below does. The walkthrough chains all three products into one coherent example: pull a real page in with Reader, vectorize it with Embeddings, then rerank a query against it with Reranker.

Step 0: get an API key

Generate one for free at jina.ai — no credit card. All three APIs use the same standard Bearer token:

Authorization: Bearer $JINA_API_KEY

Step 1: Reader — turn a URL into clean text (live-tested)

Reader’s entire interface fits in one line: append the target URL to https://r.jina.ai/, send a GET request, get Markdown back. We tested this directly against a real page rather than pulling numbers from documentation — OpenRouter’s Quickstart docs, a reasonable stand-in for the kind of page a site like this one actually needs to pull clean text from:

curl "https://r.jina.ai/https://openrouter.ai/docs/quick-start"

Actual result: HTTP 200 in 1.337s, 16,629 bytes returned. Response headers included x-usage-tokens: 4299 and x-ratelimit-limit: 20, 20;w=60 — confirming the documented 20-requests-per-60-seconds anonymous limit without needing a key at all. The output followed Reader’s fixed structure:

Title: OpenRouter Quickstart Guide

URL Source: https://openrouter.ai/docs/quick-start

Markdown Content:
> ## Documentation Index
> Fetch the complete documentation index at: [/docs/llms.txt](...)

[Skip to main content](...)
[OpenRouter | Documentation home page...]
Search...
*   [Models](...)
*   [Fusion](...)
...

The honest catch: by default Reader grabs the whole page — top nav, sidebar doc tree, and all. The actual Quickstart content doesn’t start until line 127 of a 488-line file. That’s not a bug, it’s what “no filtering” honestly looks like, and two headers fix it.

X-Target-Selector scopes extraction to a CSS selector. A generic guess — article — actually failed:

curl -H "X-Target-Selector: article" \
  "https://r.jina.ai/https://openrouter.ai/docs/quick-start"
# → HTTP 422: "No content available for URL ... with target selector article"

The page’s own “Skip to main content” link pointed at #content-area, and that one worked:

curl -H "X-Target-Selector: #content-area" \
  "https://r.jina.ai/https://openrouter.ai/docs/quick-start"

Actual result: 3,932 bytes, down from 16,629; x-usage-tokens: 843, down from 4,299 — filtering out the chrome cut both the payload and the token bill to roughly a fifth, with headings, tables, and links intact and the navigation noise gone:

Title: OpenRouter Quickstart Guide

URL Source: https://openrouter.ai/docs/quick-start

Markdown Content:
OpenRouter provides a unified API that gives you access to hundreds of AI models
through a single endpoint, while automatically handling fallbacks and selecting
the most cost-effective options.

| Approach | Best for |
| --- | --- |
| **API** | Full control, any language, no dependencies |
| **Client SDKs** | Type-safe model calls with minimal overhead |
| **Agent SDK** | Building agents with tool use, loops, and state |
...

One more real, slightly counterintuitive finding: switching X-Return-Format from the default markdown to text on the same selector-scoped request increased both size and token cost — 8,439 bytes and 2,082 tokens, roughly double the Markdown version. Markdown conversion apparently strips more UI chrome (“Copy page” buttons and similar) than plain-text extraction does. If token cost matters, don’t assume text is cheaper — test both against your actual target page.

Step 2: Embeddings — vectorize what Reader gave you

Take the cleaned-up chunks from Step 1 and embed them:

import requests

# The Markdown content Step 1 returned, split into passage-sized chunks
chunks = [
    "OpenRouter provides a unified API that gives you access to hundreds of AI models "
    "through a single endpoint, while automatically handling fallbacks and selecting "
    "the most cost-effective options.",
    "Using the OpenRouter API: send standard HTTP requests to the "
    "/api/v1/chat/completions endpoint — compatible with any language or framework.",
    "Client SDKs: type-safe model calls with minimal overhead.",
    "Agent SDK: building agents with tool use, loops, and state.",
]

response = requests.post(
    "https://api.jina.ai/v1/embeddings",
    headers={"Authorization": "Bearer your Jina AI key"},
    json={
        "model": "jina-embeddings-v3",
        "input": chunks,
        "task": "retrieval.passage"   # storage-side encoding; use retrieval.query for the search query itself
    }
)
chunk_embeddings = response.json()["data"]

Two things worth knowing here. First, the task parameter is easy to skip past but genuinely matters: for retrieval, encoding storage-side text with retrieval.passage and the query with retrieval.query performs better than using the same default encoding for both. Second, Jina deliberately shaped this endpoint’s request/response JSON to align with OpenAI’s text-embedding-3-large schema — the stated intent is to let you repoint an existing OpenAI SDK integration’s base_url at Jina instead of rewriting it. That’s schema alignment, not a certified drop-in guarantee: Jina-only parameters like task and late_chunking (next section) aren’t part of the OpenAI schema, they just don’t break anything if you omit them.

If you’re vectorizing a whole knowledge base rather than four chunks, don’t loop over this synchronous endpoint — use the asynchronous POST /v1/batch/embeddings instead: submit a job, poll GET /v1/batch/{batch_id} for status, then download the JSONL results once it completes.

Step 3: Reranker — score the chunks against a real query

Coarse retrieval (ANN vector search) typically pulls back a broad set of candidates; reranking narrows that down to the two or three you’d actually hand to an LLM. This step tends to have a good ROI — reranking a couple dozen candidates is cheap, but the lift in final answer quality is often the single biggest lever in a RAG pipeline. Jina Reranker v3 scores nDCG@10=61.94 on the BEIR benchmark and has a 131K-token context window, big enough to rerank the query plus every candidate document in one pass.

response = requests.post(
    "https://api.jina.ai/v1/rerank",
    headers={"Authorization": "Bearer your Jina AI key"},
    json={
        "model": "jina-reranker-v3",
        "query": "What's the difference between calling the API directly and using a client SDK?",
        "documents": chunks,
        "top_n": 2,
        "return_documents": True
    }
)
top_chunks = [r["document"] for r in response.json()["results"]]

On a tighter budget, jina-reranker-v2-base-multilingual trades some accuracy for lower cost and is a reasonable fit for mixed-language knowledge bases.

What’s actually verified here, and what isn’t

Being upfront about which half of this tutorial is real: the Reader numbers in Step 1 — HTTP status, byte counts, x-usage-tokens, x-ratelimit-* headers, and the one selector guess that actually failed — were captured live against https://openrouter.ai/docs/quick-start, not copied from documentation. The Embeddings and Reranker calls in Steps 2-3 follow the documented request/response schema but weren’t executed live for this page — treat their exact response shapes as accurate-to-docs rather than freshly re-verified.

If you want this same pattern extended into a full multi-document pipeline — chunking strategy, semantic entity dedup, persistent graph storage — see our complete Jina API knowledge-graph tutorial, which runs the Reader step live against real Wikipedia pages and walks through entity extraction and graph assembly end to end.

Two embeddings features worth knowing about: Late Chunking and Matryoshka

Two request parameters are easy to skip past in the docs but change how well retrieval actually performs.

Late Chunking ("late_chunking": true). The normal approach is to chunk a document first, then embed each chunk independently — so each chunk’s vector has no idea what came before or after it in the source text. Late Chunking flips the order: Jina encodes the entire document in one pass first, so every token’s representation is aware of the full surrounding context, and only then splits the result into per-chunk vectors. Jina describes this as treating the “concatenated input as a single item” — for documents where meaning depends on context spanning chunk boundaries (a pronoun referring back three paragraphs, a table referenced before it’s defined), this is a real, not cosmetic, difference.

Matryoshka Representation Learning ("dimensions": N). Embeddings v3 can be truncated to as few as 32 dimensions, and v4 down to 128, while still returning usable (if less precise) vectors. In practice, this means storing a smaller vector for a coarse first-pass filter and only paying full storage/compute cost for documents that survive that cut — a genuine lever for cutting vector-database storage costs at scale, not just a benchmark-leaderboard checkbox.

Both parameters are opt-in; leave them out and you get the default full-precision, independently-chunked behavior used in the tutorial above.

How it compares: Jina AI vs. OpenAI vs. Cohere

	Jina AI	OpenAI text-embedding-3-large	Cohere Embed v3
Free credit	10M tokens	None	None
Multimodal (image)	✓ (v4, v5-omni)	✗	✗
Built-in reranker	✓	✗	✓
Built-in web Reader	✓	✗	✗
Max context (embeddings)	32K (v4/v5)	8K	512 tokens
Multilingual support	89-100 languages	Multilingual	100+ languages
Mainland direct connect	✗, proxy required	✗, proxy required	✗, proxy required

Bottom line: if all you need is text embedding, OpenAI and Cohere are both mature, well-documented choices. If you want embeddings, reranking, and web scraping under one account and one free-token pool, Jina AI is one of the few services that packages all three — and the 10M free tokens are enough to actually test that claim before paying for it.

Integrating with LangChain

LangChain’s JinaEmbeddings class is a community-maintained integration (not an official Jina package) that wraps the same REST endpoint used above:

from langchain_community.embeddings import JinaEmbeddings
from langchain_community.vectorstores import Chroma

embeddings = JinaEmbeddings(
    jina_api_key="your Jina AI key",
    model_name="jina-embeddings-v3"
)

vectorstore = Chroma.from_texts(texts=documents, embedding=embeddings)
retriever = vectorstore.as_retriever(search_kwargs={"k": 20})

Where Jina AI fits, and where it doesn’t

Fits: internal enterprise knowledge bases, real-time web-content Q&A, multilingual semantic search, cross-modal image-text retrieval — anything where you’d otherwise be integrating three separate vendors for crawling, embedding, and reranking.

Doesn’t fit: pure text generation (Jina has no LLM of its own — pair it with AiHubMix’s Prompt Caching or Portkey’s routing for the generation side); extremely budget-sensitive simple semantic search that doesn’t need reranking, where OpenAI Embeddings plus pgvector is already enough.

Information verified 2026-07-20. Jina AI’s feature set continues to expand — refer to the official jina.ai documentation for the latest details.

Accessing from mainland China

If you’re not calling the API from mainland China, you can skip this section — Jina AI’s endpoints work directly everywhere else. For mainland China, api.jina.ai and r.jina.ai require a proxy. Two common approaches:

Option 1: local proxy forwarding Set up an HTTP proxy locally using a tool like Clash or V2Ray, and specify the proxies parameter in your code:

proxies = {"https": "http://127.0.0.1:7890"}
response = requests.post(
    "https://api.jina.ai/v1/embeddings",
    headers={"Authorization": "Bearer YOUR_KEY"},
    json={...},
    proxies=proxies
)

Option 2: through an AI API relay Some AI API relays (such as Chutes) have already integrated Jina AI’s embedding endpoint, letting you call it via a mainland direct-connect address in an OpenAI SDK-compatible format:

from openai import OpenAI

client = OpenAI(
    api_key="relay key",
    base_url="https://relay-address/v1"
)
response = client.embeddings.create(
    model="jina-embeddings-v3",
    input=["your text"]
)

The relay approach skips local proxy configuration and is well suited to production environments or team collaboration.

Related reviews

• Sub2API: a subscription-pooling relay, sharing Claude Max compute at low cost through group-buy pooling
• Chutes: global low-latency multi-model routing, friendly for A/B testing, competitively priced
• GPTAPI.US: a dual-region relay spanning China and the U.S., PayPal + Alipay dual-currency payment, stable direct connect to GPT/Claude/Gemini
• No.1-API: a one-stop model-aggregation relay with well-documented interfaces, a unified entry point for Claude/GPT/Gemini/DeepSeek