OCR Vergleich
Lokale Open-Source-OCR-Werkzeuge im Vergleich
Stand: August 2026. Fokus auf Tools, die sich lokal/selbst hosten lassen (kein Cloud-Zwang). Eigene Praxiserfahrung (⭐-markiert) stammt aus dem GIGA-Document-OCR-Benchmark-Projekt; restliche Angaben aus aktueller Marktrecherche — vor Produktivsatz am eigenen Dokumentenbestand prüfen.
Kurzübersicht: Wann welches Tool?
| Situation | Empfehlung |
|---|---|
| Digitale PDFs mit Textlayer (Verträge, DocuSign, CAD-Exporte) | Docling oder direkt PyMuPDF/pdfplumber — kein OCR nötig |
| Große Mengen einfacher Scans, keine GPU vorhanden | Tesseract |
| Mehrsprachige Dokumente, Tabellen, GPU vorhanden | PaddleOCR / PaddleOCR-VL |
| Komplexe Layouts → sauberes Markdown fürs RAG/LLM | MinerU (jetzt Apache-2.0-basiert) |
| Handschrift, sehr unregelmäßige Layouts | VLM-Ansatz (PaddleOCR-VL, Marker, Qwen-VL-Familie) |
| Kommerzielles Produkt, Lizenzprüfung durch Rechtsabteilung | Docling (MIT) oder PaddleOCR (Apache-2.0) zuerst prüfen |
Vergleichstabelle
| Tool | Ansatz | Lizenz | Hardware | Stärken | Schwächen | Am besten für |
|---|---|---|---|---|---|---|
| Tesseract | Klassische OCR-Pipeline (Erkennung pro Zeichen) | Apache-2.0 | CPU (kein GPU-Zwang, GPU/OpenCL experimentell) | Extrem etabliert, läuft überall, kostenlos, hoher Durchsatz bei sauberem Drucktext, viele Sprachpakete | Schwach bei Handschrift, komplexen Layouts, Tabellen; kein Strukturverständnis; Genauigkeit sinkt stark bei schlechten Scans/Schrägstellung | Große Archive mit sauberem gedrucktem Text, Budget = 0, kein GPU-Server verfügbar ⭐ (Backend von Paperless-ngx und GIGA.Lens' Bbox-Refine-Fallback) |
| EasyOCR | CNN+RNN-basierte klassische OCR | Apache-2.0 | GPU empfohlen, CPU möglich | Sehr schneller Einstieg (~5 Min Setup), gute Confidence-Scores, brauchbar bei gekrümmtem/fotografiertem Text (Straßenschilder-Stil) | Schwächer bei Dokumentlayout/Tabellen als PaddleOCR; weniger fürs strukturierte Dokumenten-Parsing gedacht | Schnelle Prototypen, Szenentext, einfache mehrsprachige Erkennung ohne Layoutanspruch |
| PaddleOCR / PaddleOCR-VL | Modulare klassische Pipeline plus VLM-Variante (PaddleOCR-VL 1.5+) für Layoutverständnis | Apache-2.0 | GPU für Serverpräzision, CPU für Lightweight-Modelle | 80+ Sprachen inkl. starkem CJK, gute Tabellenerkennung (PP-Structure), hoher Durchsatz auf GPU (~120 Seiten/Min), PP-OCRv6 zeigt spürbaren Genauigkeitssprung ggü. Vorgänger | Mehr Konfigurationsaufwand als leichtere Libraries; reine PaddleOCR-Basisversion ohne PP-Structure liefert nur Text, keine Struktur; Versions-Kompatibilität eng (z. B. paddlepaddle-Pins) | Produktive mehrsprachige Pipelines mit Tabellen/Formularen und GPU-Zugriff ⭐ (PP-OCRv6 in eigenen Tests klar stärkste reine OCR auf deutschen Alt-Scans; strikter Versions-Pin nötig — 3.2.2 funktioniert, 3.3.1 crasht) |
| Docling (IBM) | Ensemble spezialisierter Modelle, einheitliche API | MIT (permissiv) | CPU-fähig, dadurch langsamer als GPU-Alternativen | Sehr sauberes, lesbares Markdown; hervorragend bei digital-geborenen PDFs mit einfachem Layout; deckt viele Formate ab (PDF, DOCX, PPTX, XLSX, HTML); permissive Lizenz ohne Umsatzschwellen | Markdown-first-Design begrenzt Erhalt komplexer Layouts/strukturierter Daten; schwächer bei Scans/Handschrift | Digitale PDFs, RAG-Ingestion, wenn Lizenzprüfung schnell gehen muss ⭐ (in eigenem Benchmark durchgehend schnellster Kandidat auf born-digital PDFs — 4–6 Sek. durch Textlayer-Zugriff) |
| Marker (Datalab) | LLM-gestützte PDF-zu-Markdown-Pipeline | Code Apache-2.0, Gewichte GPL-3.0 / Umsatzschwelle 5 Mio. USD — Lizenzdatei der gepinnten Version lesen | GPU für brauchbare Geschwindigkeit, CPU-Modus deutlich langsamer | Gute Strukturerhaltung, LLM-gestützte Interpretation auch bei unsauberen Layouts | Ohne GPU langsam; Lizenzlage bei kommerziellem Einsatz separat prüfen (Gewichte ≠ Code-Lizenz) | Mittelgroße Dokumentenmengen mit GPU-Budget, wo Docling zu einfach strukturiert ⭐ (im eigenen Setup 120–180 Sek./Dokument auf CPU, benötigt gepinntes llama.cpp-Backend) |
| MinerU (OpenDataLab) | Pipeline: Layout-Erkennung → OCR (nutzt intern u. a. PaddleOCR-Modelle) → Formel-/Tabellenerkennung → Zusammenbau | Seit v3.1 (April 2026): MinerU Open Source License (Apache-2.0-Basis + Zusatzbedingungen; vorher AGPL-3.0) — Lizenzänderung erleichtert kommerzielle Nutzung deutlich | GPU/CUDA, NPU/CANN, MPS-Beschleunigung; CPU-Pipeline-Modus möglich, aber langsamer | Sehr strukturiertes Markdown/JSON, gute Formel-(LaTeX)- und Tabellen-(HTML)-Erkennung, aktive Weiterentwicklung, seit v3.4 PP-OCRv6-Backend (~11 % Genauigkeitsgewinn) | Bei komplexen Layouts/Handschrift laut eigener Doku noch ausbaufähig; Pipeline-Charakter macht Debugging vielschichtiger als Einzelmodell-Tools | RAG-Ingestion-Layer vor Chunking/Embedding, wissenschaftliche/technische Dokumente mit Formeln ⭐ (im eigenen Benchmark schnellster „schwerer" Kandidat, 30–70 Sek., aber leicht konservativere Zeichenzahl als andere Engines) |
| Surya (Datalab) | VLM-nah: Layout, Leserichtung, Texterkennung, Tabellen in einem Modell | Code Apache-2.0, Gewichte modifizierte OpenRAIL-M / Umsatzschwelle 5 Mio. USD | GPU empfohlen | Kompakt (~650 M Parameter bei vergleichbaren Modellen dieser Klasse), gutes Kosten-Genauigkeits-Verhältnis, 90+ Sprachen, layoutbewusste Ausgabe in einem Durchgang | Gewichte-Lizenz separat prüfen bei Umsatz > 5 Mio. USD; jünger/weniger etabliert als Tesseract/PaddleOCR | Layout-Analyse + OCR in einem Schritt, wenn Lizenzschwelle unproblematisch ist |
| GOT-OCR2 (StepFun) | Kompaktes, spezialisiertes OCR-Modell | Apache-2.0 | Ein einzelnes GPU-Modell ausreichend (~580 M Parameter) | Gute Leistung bei Fließtext, Formeln, Tabellen; sehr permissive Lizenz | Geringere Community-Adoption, weniger Tooling/Ökosystem als PaddleOCR oder MinerU | Schlanke Einzelmodell-Lösung ohne Pipeline-Overhead |
Nach Dokumenttyp
| Dokumenttyp | 1. Wahl | 2. Wahl | Warum |
|---|---|---|---|
| Digitale PDFs (Verträge, DocuSign, E-Rechnungen) | Docling / PyMuPDF-Textlayer direkt | — | Kein OCR nötig, Millisekunden statt Sekunden ⭐ |
| Saubere Scans, gedruckter Text | PaddleOCR | Tesseract | PaddleOCR schneller/robuster auf GPU; Tesseract als GPU-freie Alternative |
| Alte/verschlissene Scans (Flecken, Streifen, Schräglage) | PaddleOCR-VL | MinerU | VLM-Ansatz kompensiert Bildfehler besser als klassische Pipeline — Vorverarbeitung (Enhancement) vorher stark empfohlen ⭐ |
| Formulare/Tabellen | PaddleOCR (PP-Structure) | MinerU | Beide mit dedizierter Tabellenerkennung; MinerU gibt HTML-Tabellen aus |
| Technische Zeichnungen/Pläne (A0–A2) | PaddleOCR-VL | Docling (falls Textlayer vorhanden) | Große Formate brauchen Layout-/VLM-Verständnis, reines Tesseract überfordert bei Mischinhalt |
| Wissenschaftliche Dokumente mit Formeln | MinerU | Marker | Beide mit LaTeX-Formelerkennung |
| Handschrift | VLM-Ansatz (PaddleOCR-VL, Qwen-VL-Familie) | — | Klassische Pipelines (Tesseract, EasyOCR) strukturell schwach bei Handschrift |
| Mehrsprachig / CJK | PaddleOCR | Surya | Beide mit breiter Sprachabdeckung (80+ bzw. 90+ Sprachen) |
| RAG/LLM-Ingestion, gemischter Bestand | MinerU (Scans/PDF) + Docling (digital-nativ) im Zwei-Stufen-Setup | — | Günstiger Konverter zuerst, schwerer Parser nur bei Bedarf — gängiges Produktivmuster |
Lizenz-Stolperfallen (unbedingt vor Produktivsatz prüfen)
- Code- und Gewichte-Lizenz können auseinanderfallen. Bei der Datalab-Familie (Marker, Surya) ist der Code Apache-2.0, die Modell-Gewichte laufen aber unter restriktiveren Lizenzen mit Umsatzschwellen (~5 Mio. USD/Jahr). Eine Apache-Lizenz auf dem Repo sagt nichts über die Nutzbarkeit der Gewichte aus.
- MinerU hat die Lizenz gewechselt: bis Version 3.0 AGPL-3.0 (copyleft, für viele Firmen ein Ausschlusskriterium), seit v3.1 (April 2026) die „MinerU Open Source License" auf Apache-2.0-Basis mit Zusatzbedingungen — deutlich unternehmensfreundlicher, aber die genaue Version prüfen, die tatsächlich deployt wird.
- Immer die LICENSE-Datei der exakt gepinnten Version lesen, nicht nur einen Blogpost oder das GitHub-Repo-Badge — Bedingungen ändern sich zwischen Minor-Versionen.
Eigene Erfahrungswerte
Auf einem Referenzdokument (born-digital, 1 Seite) im eigenen Docker-Stack:
| Engine | Zeit | Zeichen | Anmerkung |
|---|---|---|---|
| Docling | 4–6 s | 2078 | Textlayer-Pfad, mit Abstand am schnellsten |
| MinerU | 30–70 s | 2028 | Leicht konservativer als andere |
| Marker | 120–180 s | 2124 | CPU-Modus, mit llama.cpp-Backend |
| PaddleOCR-VL | 340–450 s | 2106 | Langsamster, aber stabil nach Self-Healing-Patch |
Auf einem harten Fall (Bebauungsplan 1987, großformatiger Scan) zeigte sich zusätzlich: Vorverarbeitung entscheidet oft mehr als die Enginewahl — Beleuchtungskorrektur, Entstreifung und Deskew vor der OCR verbessern die Lesbarkeit messbar, müssen aber vorsichtig dosiert werden (zu aggressive Kontrastanhebung/Binarisierung kann blasse Schrift wieder zerstören).