PaddleOCR: An Industrial-Grade Engine from Documents to Structured Data
> PaddlePaddle/PaddleOCR | Python | 84.6K ⭐ | Apache 2.0 > GitHub: https://github.com/PaddlePaddle/PaddleOCR
---
One-Line Positioning
PaddleOCR is not "an OCR tool" — it is document AI infrastructure, turning PDFs, images, and scanned files into structured data (JSON/Markdown) that LLMs can directly consume.
It is directly integrated by leading projects such as Dify, RAGFlow, Cherry Studio, and OmniParser. In the era of RAG and Agents, it is the essential bridge from images/PDFs to text.
---
Three Product Lines
1. PP-OCRv6 — Scene Text Recognition (released June 2026)
- Unified model for 50 languages: Chinese, English, Japanese + 46 Latin-script languages, no model switching needed
- 34.5M parameters (medium version), runs on CPU faster than mainstream VLMs
- 5.2× CPU acceleration (OpenVINO), 6.1× on Apple M4, 0.13s on A100 GPU
- Three tiers: tiny (1.5M) / small (7.7M) / medium (34.5M), covering edge to server
- 96.3% accuracy on OmniDocBench v1.6, a new SOTA among both open-source and closed-source solutions
- 0.9B parameters, NaViT dynamic-resolution vision encoder + ERNIE-4.5-0.3B language model
- Outputs Markdown or JSON; supports tables, formulas, seals, charts, ancient texts, and rare characters
- Automatic cross-page table merging for long documents, hierarchical heading recognition
- Fine-grained coordinate information: table cell coordinates, text coordinates, layout analysis
- Difference from PaddleOCR-VL: VL focuses on large-block text understanding; StructureV3 focuses on precise positions + structure
- Supports Word/Excel/PowerPoint → Markdown conversion
- GitHub: https://github.com/PaddlePaddle/PaddleOCR
- Official site: https://www.paddleocr.com
- PaddleOCR-VL-1.6 paper: arXiv:2606.03264
- PaddleOCR 3.0 technical report: arXiv:2507.05595
A key number: PP-OCRv6 improves detection accuracy over PP-OCRv5 by 4.6% and recognition accuracy by 5.1%, while surpassing mainstream VLMs like Qwen3-VL-235B and GPT-5.5. Beating a 235B model with 34.5M parameters — that is the power of architecture optimization.
2. PaddleOCR-VL-1.6 — Document Parsing VLM (0.9B, SOTA)
The core design of this model is resource efficiency. At 0.9B parameters, its document parsing capability exceeds many 10B+ general-purpose VLMs. It doesn't just "understand images" — it "specifically understands documents."
3. PP-StructureV3 — Structured Extraction
---
Ecosystem Integration: Not Just a Tool, but Infrastructure
PaddleOCR's integration matrix:
| Integration Direction | Projects/Platforms | |---------|----------| | Agent workflows | Dify, RAGFlow, Cherry Studio, Pathway | | MCP | Official MCP Server, direct Agent calls | | LangChain | langchain-paddleocr package | | Browser | PaddleOCR.js SDK, PP-OCRv5 runs directly in the browser | | Deployment | Docker, C++ Serving, ONNX Runtime, TensorRT, OpenVINO | | Multi-language SDKs | Go, TypeScript, Java, C++, C# | | Mobile | Android/iOS SDK |
Referenced by 6,500+ projects. This is not a popularity contest — it's downstream projects voting with their feet: anyone building RAG and Agents cannot avoid the document parsing step.
---
Why Look at This Project Now
Three trends converging:
1. RAG needs document input — 80% of enterprise knowledge bases are PDFs and scans; no OCR, no RAG 2. Agents need structured data — visual agents (e.g., OmniParser) need screens/documents converted into operable structures 3. On-device inference is becoming a hard requirement — a 0.9B VLM running on CPU/mobile; privacy-sensitive scenarios can't go to the cloud
The release cadence of PaddleOCR 3.7.0 (June 11, 2026) lands exactly at the intersection of these three trends.
---
One Detail
PaddleOCR's VLM route (PaddleOCR-VL-1.x) and the traditional pipeline route (PP-OCRv6 + PP-StructureV3) are parallel, not replacements. The VLM is better suited for "understanding" (where this text sits in a table, the relationship between formulas and context), while the pipeline is better for "precise extraction" (coordinates, fonts, seal positions). The two are complementary, covering different scenarios.
This reflects a mature philosophy from the Baidu PaddlePaddle team: don't bet on a single route — cover the full stack.
---