PP-OCRv6 models: tiny, small and medium compared

What PP-OCRv6 is (and what "PaddleOCR v6" isn't)#

PP-OCR is the name of PaddleOCR's text-line OCR system: a detection model that finds every line of text and returns a polygon, and a recognition model that reads the cropped line. PP-OCRv6 is the sixth generation of that model pair. It was released on June 11, 2026 together with the paddleocr package version 3.7.0, which made it the default.³

The version numbers are easy to mix up. There is no "PaddleOCR v6" package — the latest package is PaddleOCR 3.7.0. "v6" is the model generation. The same package can still load PP-OCRv5, v4 and v3 models, and it does so automatically for languages that PP-OCRv6 doesn't cover (see below).

Baidu describes PP-OCRv6 as one family with three tiers aimed at edge/IoT (tiny), mobile/desktop (small) and server (medium) use. The headline change from PP-OCRv5 is language coverage: the small and medium recognizers read 50 languages with one model — simplified Chinese, traditional Chinese, English, Japanese and 46 Latin-script languages — so you no longer need a separate model for French or Vietnamese.¹ If you just call PaddleOCR(), you get the medium tier:⁶

from paddleocr import PaddleOCR

ocr = PaddleOCR()   # lang=None, ocr_version=None -> PP-OCRv6_medium_det + PP-OCRv6_medium_rec

The three tiers: parameters, sizes, languages#

Each tier is two models, PP-OCRv6_<tier>_det and PP-OCRv6_<tier>_rec. Parameter counts come from the Hugging Face model cards; sizes are the figures in the official module docs, which match the Hugging Face files when you count in MiB (1,048,576 bytes).⁴⁵

The det + rec parameter counts add up to the tier totals Baidu publishes (1.5M / 7.7M / 34.5M) after rounding.³ Totals in the MB column are our sums of the published per-model sizes.

The tiny tier can't read Japanese — we measured how badly#

The official docs mention this in a single clause ("tiny supports 49, excluding Japanese") and the OCR pipeline doc adds that PP-OCRv6_tiny does not support japan.¹⁷ The Chinese version of the algorithm doc gives the reason: Japanese was left out to avoid the impact of about 4,000 kanji and kana characters on the tiny recognizer's 1.1M-parameter output layer.² We counted the dictionaries shipped with each model: tiny has 6,904 entries and no hiragana or katakana at all; small and medium each have 18,708 entries, 180 of them kana.¹²

What that means in practice: on our Japanese shop notice, tiny's character error rate was 47.3%, against 0% for small and medium. Only 1 of 8 lines came out right — the one made of kanji and digits. PaddleOCR doesn't warn you, and the confidence scores stay high enough to fool a threshold filter:¹¹¹²

Every kana is replaced by a look-alike from tiny's dictionary: の becomes ⑦, お becomes 书, し becomes L. Medium and small read all eight lines correctly. If your input might contain Japanese, use small or medium; in the browser, our online tool uses small by default for this reason.

How PP-OCRv6 works, in plain words#

• One backbone for both jobs. PPLCNetV4 follows the MetaFormer pattern (a cheap "token mixer" followed by a "channel mixer"), and uses structural reparameterization: extra branches help during training and are folded into a single convolution for inference. For detection it shrinks the image in both directions; for recognition it shrinks only the height, so a text line becomes a left-to-right sequence.¹
• Detection sees wider context. The new RepLKFPN neck uses 7×7 depthwise convolutions instead of 3×3 and has 31% fewer parameters than PP-OCRv5's RSEFPN (118K vs 172K).¹
• Recognition mixes local and global views. The EncoderWithLightSVTR neck combines a small convolution for neighbouring characters with one or two self-attention layers for the whole line. A CTC head produces the text; an NRTR head helps only during training and is removed at inference.¹
• Tiny is distilled. The tiny recognizer has no neck at all and is trained to imitate the medium model (knowledge distillation).¹
• One dictionary for 50 languages. The character set was extended with about 200 diacritical characters, which is what lets one model read Polish, Vietnamese or Icelandic alongside Chinese.¹

Official accuracy: PP-OCRv6 vs PP-OCRv5#

These numbers are Baidu's own, measured on its in-house multi-scenario benchmark — 16 detection categories and 15 recognition categories. The test set isn't public, so treat them as vendor-reported.¹

Two things stand out. Small (7.7M parameters) beats the much larger PP-OCRv5 server on both averages. And tiny's recognition average (73.5%) is level with PP-OCRv5 mobile (73.7%) at roughly a third of the download — but it falls far behind on handwriting, as the category tables show.

Detection Hmean by category (%)#

The biggest detection gain is on rotated text (93.8 vs 80.0 for v5 server). PP-OCRv5 server still edges medium on tables (97.1 vs 96.8) and handwritten English (84.1 vs 84.0).¹

Recognition accuracy by category (%)#

Baidu highlights the Japanese (+16.8 points), ancient-text (+12.0) and screen-text (+14.4) gains of medium over v5 server.² Note the odd row in this table: tiny scores 89.8% on Japanese, close to medium, even though it can't read kana. The docs don't explain the test set behind this cell; for real Japanese text, trust the measured result above.

The same tables also include vision-language models (Gemini-3.1-Pro, GPT-5.5, Qwen3-VL-235B), all of which score lower than PP-OCRv6 medium on Baidu's set; that is the basis of the claim that the 34.5M-parameter model "surpasses VLMs".¹

Size vs accuracy#

Going from tiny to small costs 24 MB and buys 7.8 accuracy points; going from small to medium costs another 103 MB for 1.9 points. Against the previous generation, small beats PP-OCRv5 mobile by 7.6 points for 9 MB more, medium beats PP-OCRv5 server by 5.1 points while being smaller, and tiny matches PP-OCRv5 mobile at under a third of its size.

Official speed tables (with hardware)#

Baidu timed the full pipeline — image loading, pre- and post-processing and both models — on 200 general and document images. Values are seconds per image. The doc names the hardware but not thread counts or batch settings.¹

Read it by row, not by headline. On a GPU, medium is barely faster than v5 server on A100 (0.29 vs 0.32 s) and slower on V100 with PaddlePaddle (0.72 vs 0.66 s). The large speedups Baidu quotes — 5.2× for medium with OpenVINO, 6.1× for tiny on Apple M4 — come from CPU rows where PP-OCRv5 server or mobile is unusually slow.¹ On Apple Silicon, ONNX Runtime beat PaddlePaddle for every model in this table.

The module docs also publish per-model timings for four inference engines (PaddlePaddle static and dynamic graph, Transformers, ONNX Runtime) on an NVIDIA A100 and a Xeon Gold 6248, but don't say which device produced which number, so we don't reproduce them here.⁴

Our CPU benchmark: accuracy, speed, memory, disk#

We ran all five current models on a 4-vCPU Intel Xeon @ 2.10 GHz with 15 GB RAM and no GPU, using PaddleOCR 3.7.0 with two engines: PaddlePaddle 3.2.0 and ONNX Runtime. The test set is five documents with 124 known text items — a clean receipt, the same receipt photographed at an angle, an English invoice, a Chinese + English notice and a Japanese notice. Each number is the median of three warm runs; document orientation, unwarping and line orientation were switched off. Full method and raw data are on our benchmarks page.¹¹

How to read the columns: CER is the character error rate after normalising full-width punctuation, dashes and spaces on both sides, averaged over the documents. Peak RAM is the peak resident memory of the whole Python process while it ran all five documents. On disk is the downloaded det + rec model folders for the PaddlePaddle engine, in decimal megabytes (10⁶ bytes); the ONNX folders are within 1 MB of these.¹¹

What we take from it:

• Medium is the most accurate model we tested — its only miss in 124 items was "600x600" on the invoice read as "600×600" with a multiplication sign, a slip every model made. It also beat PP-OCRv5 server on both accuracy (123 vs 117) and speed (4.51 vs 5.25 s with PaddlePaddle).
• Small is the sweet spot on CPU. About 3.3× faster than medium with ONNX Runtime, 36–42% less peak memory, under a quarter of the download, and only two more misses: "Order" read as "0rder" on both receipts.
• Tiny is genuinely tiny and fast — 0.26 s per page — and outside Japanese its error rate (0.46%) was close to PP-OCRv5 server's (0.43%).
• The PP-OCRv5 server + ONNX Runtime anomaly. PP-OCRv5 server took 35.7 s per page under ONNX Runtime, against 5.2 s with PaddlePaddle; the text output was identical. Baidu's own Xeon rows show the same direction, though far less extreme (6.36 s ONNX Runtime vs 2.04 s PaddlePaddle). A later check with lang="korean", which uses the same v5 server detector with a small Korean recognizer, showed the same pattern (12.35 s vs 1.80 s per image), so the detector looks like the slow part. If you need v5 server or a PP-OCRv5 language on CPU, use the PaddlePaddle engine.¹¹⁴
• Our CPU result for medium differs from Baidu's Xeon 8350C row, where ONNX Runtime (3.31 s) was slower than PaddlePaddle (2.05 s). Different CPUs, thread counts and engine versions move these numbers a lot — benchmark on your own hardware before committing.

Which tier should I use?#

Sources: the PaddleOCR.js source and the iOS and Android deployment docs for the platform rows; Baidu's tables above for accuracy; our benchmark for speed.¹¹¹¹³ Try small and tiny side by side on your own image with the online OCR tool.

How to select a tier in Python and the CLI#

This is the part that trips people up: lang and ocr_version can only ever select the medium tier. For any PP-OCRv6 language, PaddleOCR 3.7 returns PP-OCRv6_medium_det + PP-OCRv6_medium_rec. To get small or tiny, name the models explicitly:⁶

from paddleocr import PaddleOCR

ocr = PaddleOCR(
    text_detection_model_name="PP-OCRv6_small_det",     # or PP-OCRv6_tiny_det
    text_recognition_model_name="PP-OCRv6_small_rec",   # or PP-OCRv6_tiny_rec
    use_doc_orientation_classify=False,
    use_doc_unwarping=False,
    use_textline_orientation=False,
    engine="onnxruntime",   # optional: fastest CPU engine in our test
)
for res in ocr.predict("receipt.jpg"):
    print(res["rec_texts"])

paddleocr ocr -i receipt.jpg \
    --text_detection_model_name PP-OCRv6_small_det \
    --text_recognition_model_name PP-OCRv6_small_rec \
    --use_doc_orientation_classify False \
    --use_doc_unwarping False \
    --use_textline_orientation False \
    --engine onnxruntime

When you pass a model name or directory, PaddleOCR ignores lang and ocr_version and logs this warning:⁶

`lang` and `ocr_version` will be ignored when model names or model directories are not `None`.

So PaddleOCR(lang="japan", text_recognition_model_name="PP-OCRv6_tiny_rec") runs tiny on your Japanese text without complaint. Other selections:

• Previous generations: PaddleOCR(ocr_version="PP-OCRv5") loads PP-OCRv5_server_det + PP-OCRv5_server_rec. ocr_version="PP-OCRv4" works only for lang="ch" and "en" and loads the v4 mobile models. Any other version string raises ValueError.⁶
• Other scripts: PaddleOCR(lang="korean") loads PP-OCRv5_server_det + korean_PP-OCRv5_mobile_rec. Our language code finder shows the model for every code.
• Browser: PaddleOCR.js maps ocrVersion: "PP-OCRv6" to the small tier; tiny needs explicit model names there too. See the PaddleOCR.js guide.
• Inside PP-StructureV3: it still reads text with PP-OCRv5 server by default; passing the PP-OCRv6 models fixed three misread lines on our invoice. How.

The code generator writes these snippets for you, including the HTTP and JavaScript versions.

Scripts outside PP-OCRv6: the PP-OCRv5 multilingual models#

PP-OCRv6 covers Chinese, Japanese and Latin-script languages. Everything else in PaddleOCR 3.7 is served by small PP-OCRv5 recognizers released between June and October 2025, paired with the PP-OCRv5_server_det detector. The accuracy figures are Baidu's, each on its own test set, so compare them only with the "previous generation" column.⁸

Two further PP-OCRv5 multilingual models, latin_ and en_PP-OCRv5_mobile_rec, are now mostly superseded by PP-OCRv6; 3.7 still loads the Latin one for Pali (pi), which PP-OCRv6 explicitly excludes.⁶ One code, ka, only has a PP-OCRv3 model. The full routing for all 112 codes is on the languages page.

PP-OCRv5 vs PP-OCRv6 at a glance#

Should you upgrade? For Chinese, English, Japanese and Latin-script text, yes. In both Baidu's numbers and ours, medium and small are more accurate than v5 server and v5 mobile. On our CPU, medium was also faster than v5 server; small was slightly slower than v5 mobile (0.90 vs 0.73 s with ONNX Runtime) but made four fewer misses. Stay on v5 only for scripts v6 doesn't cover, or when you need to reproduce older output exactly.¹¹¹

PP-OCR version history#

1. 2020-05-14First lightweight model — "Open source 8.6M lightweight Chinese OCR model".⁹
2. 2020-09PP-OCR — the first named system; paper arXiv:2009.09941 (September 21, 2020).⁹
3. 2021-09-07PP-OCRv2 — released with PaddleOCR 2.3; arXiv:2109.03144.⁹
4. 2022-05-09PP-OCRv3 — released with PaddleOCR 2.5; paper arXiv:2206.03001 followed in June. Its recognizers are still the only option for lang="ka" in 3.7.⁹
5. 2023-08-07PP-OCRv4 — release/2.7, mobile and server versions. The only generation without a paper in the official list.⁹
6. 2025-05-20PP-OCRv5 — released with PaddleOCR 3.0. In 3.0.1 (June 5, 2025) the default switched from mobile to server.⁹
7. 2025-06 → 10PP-OCRv5 multilingual — 3.1.0 added recognizers for 37 languages including French, Spanish, Russian and Korean; 3.2.0 English, Thai and Greek; 3.3.0 Cyrillic, Arabic, Devanagari, Telugu and Tamil.³⁹
8. 2026-06-11PP-OCRv6 — tiny, small and medium tiers, 50 languages in one model; default in PaddleOCR 3.7.0. Paper arXiv:2606.13108.³⁹

For package releases rather than model generations, see PaddleOCR releases; to move old 2.x code to the 3.x API, use the migration guide.

Where the official sources disagree#

We found these conflicts while checking every number on this page. Where we had to pick, we used the source code or the actual files.

• "2.37× GPU inference speedup." The PP-OCRv6 doc's opening paragraph claims it for medium over PP-OCRv5 server, but the speed table in the same document shows 0.29 vs 0.32 s on A100 (which the doc itself calls "1.1× faster") and medium slower on V100 with PaddlePaddle and TensorRT. We found no table that supports 2.37×. The README cites different figures: 5.2× on CPU with OpenVINO, 6.1× for tiny on Apple M4.¹³
• 48 or 50 languages? The English doc and the recognition model cards say 50. The three detection model cards on Hugging Face say "Supports 48 languages", and the Chinese doc says 48 in one place and 50 in another. The code accepts 52 PP-OCRv6 codes, two of which are aliases (french, german) — 50 languages.²⁵⁶
• Model sizes. PP-OCRv5_server_det is 84.3 MB in the module docs and 101 MB in model_list.md; its files add up to 84.24 MiB. ch_RepSVTR_rec is 22.1 MB in one doc and 48.8 MB in two others. The Korean, Latin and East Slavic v5 recognizers are listed at 14 MB each, but their files are 13.0, 7.8 and 7.7 MiB. Published "MB" figures are effectively MiB; our on-disk numbers above are decimal MB of the whole model folder, so they read a few percent higher.⁴⁵¹⁰
• Same model, different scores. PP-OCRv5_server_rec is 86.38%, 0.8401 or 78.1% depending on which document you read — three different benchmarks (see the callout above).⁴⁸
• 106 or 109 languages for PP-OCRv5 multilingual? The v5 multilingual doc says 106; the README, after the October 2025 release, says 109.³⁸
• Missing PP-OCRv6 rows. model_list.md shows "-" for PP-OCRv6 accuracy, latency and size, and the standard T4 latency tables list PP-OCRv6 as "- / -".⁴¹⁰

If you spot another, or one of these gets fixed upstream, email hello@paddleocr.dev.

Questions#