PP-OCRv6 print: PaddleOCR's compact OCR engine as an API

PP-OCRv6 is Baidu PaddlePaddle's newest compact OCR family, released on 11 June 2026. It spans three tiers from 1.5M to 34.5M parameters. One model reads 50 languages, and its publisher reports detection and recognition accuracy above the previous server generation. On this platform it is the engine of the print OCR lane. The lane answers the ocr-print alias over a multipart route: page images and PDFs in, text out, metered per page from a prepaid wallet. The lane is built and measured, and its rate is set. The public models list does not carry it yet, and no date is promised. The models index carries the catalog's current state and changes the day the lane joins it.

This page covers what the model is and the family split that confuses most searches. It covers the exact call and its laws. It also carries two layers of evidence: our own dated measurements from the hosted lane, and the publisher's benchmark tables read at source.

Last verified: 2026-09-25

What it is

PP-OCRv6 is a two-stage OCR system. A detector finds text regions on the page, and a recognizer reads each cropped line. The official documentation describes the redesign that defines the generation. It has a PPLCNetV4 backbone shared by both stages, a RepLKFPN detection neck, and an EncoderWithLightSVTR recognition neck. None of that needs to matter to a caller. What matters is the shape of the family:

The compact-OCR claim in the technical report is specific. At 34.5M parameters the medium tier outperforms PP-OCRv5_server on the publisher's benchmark. In the same tables it also outperforms the general vision-language models the team ran for comparison. That last comparison is the vendor measuring other companies' systems on its own benchmark, so hold it to that standard. The narrower claim is the paper's thesis, and it matches its speed tables. A purpose-built OCR engine with orders of magnitude fewer parameters beats general VLMs on dedicated OCR work.

One disambiguation saves real confusion: PP-OCRv6 and PaddleOCR-VL are different products. PP-OCRv6 reads text out of page images. PaddleOCR-VL is a roughly 0.9B vision-language model for document parsing. It outputs layout, tables, formulas, charts, and Markdown. Search results for PaddleOCR APIs mix the two freely. Most third-party hosting found under the PaddleOCR name today serves the VL model. This platform's print lane is built on the compact engine, and the parsing category covers the platform's document-reading catalog.

Here the model runs in CPU mode on the hosted lane as a volume lane. When the lane was benched live, both candidate tiers were measured on the same nine hard ground-truth pages. Their character error rates tied to within one ten-thousandth (0.3711 small against 0.3710 medium). The small tier ran roughly three times faster per page, so the recorded tier verdict is small. The measurement record is named in the benchmarks section below.

Choosing a tier

The three tiers are one family at three sizes, and the official documentation publishes the full table. As an API choice, the rows that matter:

All accuracy figures are the publisher's in-house benchmark, the same tables quoted with dates in the benchmarks section below. The lane runs the small tier per the recorded tier verdict. Accuracy tied with medium on the bench corpus, and it runs roughly three times faster per page. Two facts are worth memorizing before you pick a tier anywhere. Tiny drops Japanese, while small and medium carry all 50 languages in one model. There is no per-language model switching at any tier. That is the practical difference from engines that need a language pack per document. The route takes an optional language hint either way. For quality in a specific language the honest answer is to test on your own pages. The publisher's benchmark is a multi-scenario in-house set, not a per-language report card.

Use cases

Printed pages at volume are this lane's profile: per-page metering, one multipart request per batch, 50 languages from one model. The cost is one you can budget before you send anything. The metered unit is the page, and the rate is listed on the pricing page when the lane goes live.

• Document backfiles in many languages. One model covers the Latin-script tail plus Chinese and Japanese. A mixed backfile needs no per-language routing and no language packs.
• Invoices, receipts, and order forms. Machine-printed pages are the strength class. In the publisher's benchmark tables, printed-English recognition sits at 93.3 for the small tier and 94.1 for medium, the top of the table.
• Search and RAG ingestion. Text out of page images is the raw material for chunking and embedding; the JSON answer feeds a pipeline directly.
• Agents that read documents. A per-page lane with a prepaid wallet bounds what a runaway loop can spend. At zero balance the next page request is refused, and refused requests bill nothing.
• Batch PDF digitization. The lane rasterizes PDF pages at 200 DPI before recognition. A scanned PDF is one file part per shot or a page-range chunk.

The print lane and the archival lane

This platform's OCR family runs two lanes over the same route family, and the split is deliberate. The print lane (ocr-print, this page) is the volume lane: compact engine, per-page metering, built for machine-printed pages at scale. The archival lane (ocr-archival) is the fidelity lane: a heavier model for hard historical documents. A diplomatic mode preserves original spelling and layout quirks instead of normalizing them. Printed business documents and born-digital scans route to print. Dense old print, unusual typefaces, and verbatim-transcript work route to archival. Both meter pages the same way. A pipeline can sit on one lane and hand the other the pages it fails.

Self-host, official cloud, or a metered lane

Apache 2.0 means the self-host road is fully open, and for this model it is a real road, not a gesture. Install with pip install paddleocr (3.7.0 at the time of writing). ONNX weights sit in the Hugging Face collection, with a Transformers backend and community ONNX deployments such as RapidOCR that skip the Paddle runtime entirely. PaddlePaddle also runs a first-party cloud with a free tier covering 20,000 pages of document parsing per day at the time of writing. Python, TypeScript, and Go SDKs and a CLI are available.

The decision rule is the usual one. Self-host when the machine is already there. Self-host when you need fine-tuning or dictionary control, or when documents cannot leave your boundary. Use the first-party cloud to prototype. Call a metered lane when you want the runtime, the metering, and the measurements to be someone else's maintenance. Your cost per page becomes a number you can put in a budget. This platform's lane bills per page from a prepaid wallet, and nothing about your spend depends on a rate limit changing.

What per-page metering means

The category search asks whether there is a free OCR API, and the open-weights answer is genuinely free. Apache 2.0 weights, your own machine, no meter, forever. What a hosted lane sells is the work around the weights. This platform meters that work per page, the unit that matches what the engine actually does. The shape of the meter follows. The engine reports a page count, and that count is what bills. When it reports none, the count of file parts stands in, since each image part is a page. A request refused at the door, an oversized one included, bills nothing. A failed batch is not billed. Job mode bills exactly once, at the status read that observes the finished job, never at creation. Spend stops at the wallet balance, so a runaway pipeline cannot outrun its funding. The rate itself appears on the pricing page the day the lane joins the public list. Until then no rate renders anywhere, which is the honest state of a model that is built and measured but not yet listed.

API usage

The route family has three endpoints, all authenticated with a Bearer key from the console:

The batch request is multipart/form-data. The accepted set of form fields includes these:

A field outside the accepted set fails with a parameter error before the request is relayed, and so does a duplicated field. Both are loud on purpose. A silent ignore or a silent last-wins would ask the engine a different question than the one you asked. Four laws of the route save debugging time:

1. A batch is not a stream. The whole batch is processed, then one JSON answer carries the recognized text and the processed page count. Set client timeouts to 120 seconds and do not expect bytes before the work is done: a batch that outgrows its 90-second budget fails with a 503 on purpose, and the fix is fewer pages per request or job mode, never a bigger timeout.
2. 25 MiB per request, firm. The cap is enforced at the door with a 413, and nothing is billed. Larger documents are the client's to chunk: split the PDF into page ranges, send multiple requests, or enqueue jobs.
3. Metering follows pages, with a fallback. The metered count is the page count the engine reports; if it reports none, the count of file parts you sent stands in. A successful OCR never bills as free.
4. Jobs bill once, and answer once. Creating a job bills nothing. The status read that observes the finished job bills its pages, and the finished payload is served exactly once: persist it when you read it, because a re-poll answers a not-found envelope, and unread jobs expire on the lane's cleanup timer (the default backstop is an hour). There is no idempotent replay on these multipart routes, so a retrying client re-executes and re-bills; check your retry settings before production traffic.

curl

curl -X POST "https://api.ironstratum.com/v1/ocr" \
  -H "Authorization: Bearer $KEY" \
  -F "model=ocr-print" \
  -F "mode=print" \
  -F "file=@page-001.png" \
  -F "file=@page-002.png"

Two file parts is a two-page batch: the answer is one JSON body for both.

python

import os
import requests

resp = requests.post(
    "https://api.ironstratum.com/v1/ocr",
    headers={"Authorization": "Bearer " + os.environ["KEY"]},
    files=[
        ("file", ("page-001.png", open("page-001.png", "rb"), "image/png")),
        ("file", ("page-002.png", open("page-002.png", "rb"), "image/png")),
    ],
    data={"model": "ocr-print", "mode": "print"},
    timeout=120,  # the whole batch answers in one JSON body; give it room
)
resp.raise_for_status()

answer = resp.json()
print("pages reported:", answer.get("pages"))

openai-sdk

The OpenAI SDK has no OCR resource, and this route family is multipart. The batch call is cleanest through curl or requests as above. The SDK does drive the route family's JSON leg, the job-status read. It works with the OpenAI client you already have configured:

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://api.ironstratum.com/v1",
    api_key=os.environ["KEY"],
)

status = client.get(
    "/ocr/jobs/" + os.environ["JOB_ID"],
    cast_to=dict,
    options={"params": {"model": "ocr-print"}},
)
print(status)

The model query parameter is required on every job read. The gateway holds no job state, so the id alone cannot route. Persist the done payload the moment you read it; it is not re-fetchable.

Benchmarks

Both evidence layers below carry their dates.

The platform's own measurements. From the measurement records of the September 2026 bench windows, the same records that pinned the lane's tier:

Read the error-rate row in context. The bench corpus is hard, dense historical print, the kind where ground truth itself is uneven. The dense-page error class was identical across both tiers. The tie is the finding. On that corpus the tiers were indistinguishable in accuracy, and the small tier was three times faster. That is why the lane runs it. Per-page wall time on real pages is dominated by image size and text density. The official speed table below is the cleaner cross-platform reference.

The model itself. From the official documentation and the release announcement, read 11 September 2026. All accuracy figures are the publisher's in-house multi-scenario benchmark.

The print-relevant columns of the same tables follow. Printed-English recognition runs 88.4 (tiny), 93.3 (small), 94.1 (medium), against 85.1 for PP-OCRv5_server and 86.0 for PP-OCRv5_mobile. Printed-English detection runs 92.3, 93.6, and 93.7, against 91.7 for v5_server. Printed text is where the model is strongest, which is the point of a print lane.

Speed comes end to end per image, including preprocessing and postprocessing, from the official table. Small runs 0.79 s and medium 2.05 s on an Intel Xeon 8350C under Paddle Inference. Small runs 3.07 s on an Apple M4 and 0.25 s on an A100. The headline CPU speedup the publisher quotes, 5.2x, is the medium tier under OpenVINO on that same Xeon against PP-OCRv5_server (1.40 s vs 7.30 s). It is real, and it belongs to that configuration. This page quotes it only with its qualifiers.

Two caveats come from the same tables. Handwriting is the weakest class (medium recognition: 62.1 on handwritten Chinese, 67.8 on handwritten English), so a handwriting-heavy workload should test before committing. Print, the lane's purpose, is where the model sits at the top of its own table. And the VLM comparisons in the official tables are the publisher's own runs of Gemini, GPT, and Qwen models on its benchmark. They are evidence of direction, not a neutral audit. Your acceptance test is your own pages, in your own languages, against the lane.

Getting started

1. Open an account through the console's invite flow. The platform runs as an invite-only beta in this phase; the console holds the wallet, the keys, and the spend history.
2. Create an API key. Keys are revocable on the spot and stand alone, so one key per project keeps a leaked one from touching anything else. The wallet balance, not a per-key cap, is the spend boundary.
3. Check the rate once. Metering is per page, and the pricing page carries the rate when the lane goes live: pages times rate, known before you send.
4. Make the first call. The curl tab with one page image is the whole contract: a key, the alias, and a file part. When one page reads back clean, the rest is batch arithmetic.

The parsing category lays out the platform's document-reading models, including the archival lane for fidelity work, and the models index lists everything the catalog serves.