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 (⭐) stammt aus dem GIGA-Document-OCR-Benchmark-Projekt; restliche Angaben aus Marktrecherche — vor Produktivsatz am eigenen Dokumentenbestand prüfen.
Kurzübersicht
| Situation | Empfehlung |
|---|---|
| Digitale PDFs mit Textlayer | Docling oder direkt PyMuPDF/pdfplumber |
| Viele einfache Scans, keine GPU | Tesseract |
| Mehrsprachig, Tabellen, GPU vorhanden | PaddleOCR / PaddleOCR-VL |
| Komplexe Layouts → Markdown fürs RAG/LLM | MinerU |
| Handschrift, unregelmäßige Layouts | VLM-Ansatz (PaddleOCR-VL, Marker) |
| Lizenzprüfung durch Rechtsabteilung nötig | Docling (MIT) oder PaddleOCR (Apache-2.0) zuerst |
Tesseract
Ansatz: Klassische OCR-Pipeline, Zeichen für Zeichen Lizenz: Apache-2.0 Hardware: CPU (kein GPU-Zwang)
Stärken: Extrem etabliert, läuft überall, kostenlos, hoher Durchsatz bei sauberem Drucktext, viele Sprachpakete. Schwächen: Schwach bei Handschrift, komplexen Layouts, Tabellen. Kein Strukturverständnis. Genauigkeit sinkt stark bei schlechten Scans oder Schräglage. Am besten für: 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
Ansatz: CNN+RNN-basierte klassische OCR Lizenz: Apache-2.0 Hardware: GPU empfohlen, CPU möglich
Stärken: Sehr schneller Einstieg (~5 Min Setup), gute Confidence-Scores, brauchbar bei gekrümmtem/fotografiertem Text. Schwächen: Schwächer bei Dokumentlayout und Tabellen als PaddleOCR. Am besten für: Schnelle Prototypen, Szenentext, einfache mehrsprachige Erkennung ohne Layoutanspruch.
PaddleOCR / PaddleOCR-VL
Ansatz: Modulare klassische Pipeline, plus VLM-Variante (PaddleOCR-VL 1.5+) für Layoutverständnis Lizenz: Apache-2.0 Hardware: GPU für Serverpräzision, CPU für Lightweight-Modelle
Stärken: 80+ Sprachen inkl. starkem CJK, gute Tabellenerkennung (PP-Structure), hoher Durchsatz auf GPU (~120 Seiten/Min). PP-OCRv6 zeigt spürbaren Sprung ggü. Vorgänger. Schwächen: Mehr Konfigurationsaufwand als leichtere Libraries. Reine Basisversion ohne PP-Structure liefert nur Text, keine Struktur. Versions-Kompatibilität eng. Am besten für: 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)
Ansatz: Ensemble spezialisierter Modelle, einheitliche API Lizenz: MIT (permissiv) Hardware: CPU-fähig, dadurch langsamer als GPU-Alternativen
Stärken: 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. Schwächen: Markdown-first-Design begrenzt Erhalt komplexer Layouts/strukturierter Daten. Schwächer bei Scans/Handschrift. Am besten für: Digitale PDFs, RAG-Ingestion, wenn Lizenzprüfung schnell gehen muss. ⭐ Im eigenen Benchmark durchgehend schnellster Kandidat auf born-digital PDFs — 4–6 Sek. durch Textlayer-Zugriff.
Marker (Datalab)
Ansatz: LLM-gestützte PDF-zu-Markdown-Pipeline Lizenz: Code Apache-2.0, Gewichte GPL-3.0 mit Umsatzschwelle 5 Mio. USD — Lizenzdatei der gepinnten Version lesen Hardware: GPU für brauchbare Geschwindigkeit, CPU-Modus deutlich langsamer
Stärken: Gute Strukturerhaltung, LLM-gestützte Interpretation auch bei unsauberen Layouts. Schwächen: Ohne GPU langsam. Lizenzlage bei kommerziellem Einsatz separat prüfen (Gewichte ≠ Code-Lizenz). Am besten für: 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)
Ansatz: Pipeline aus Layout-Erkennung, OCR (nutzt intern u. a. PaddleOCR-Modelle), Formel-/Tabellenerkennung, Zusammenbau Lizenz: Seit v3.1 (April 2026) MinerU Open Source License (Apache-2.0-Basis + Zusatzbedingungen), vorher AGPL-3.0 — Wechsel erleichtert kommerzielle Nutzung deutlich Hardware: GPU/CUDA, NPU/CANN, MPS-Beschleunigung; CPU-Pipeline-Modus möglich, aber langsamer
Stärken: Sehr strukturiertes Markdown/JSON, gute Formel-(LaTeX)- und Tabellen-(HTML)-Erkennung, aktive Weiterentwicklung. Seit v3.4 PP-OCRv6-Backend (~11% Genauigkeitsgewinn). Schwächen: Bei komplexen Layouts/Handschrift laut eigener Doku noch ausbaufähig. Pipeline-Charakter macht Debugging vielschichtiger als Einzelmodell-Tools. Am besten für: 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)
Ansatz: VLM-nah — Layout, Leserichtung, Texterkennung, Tabellen in einem Modell Lizenz: Code Apache-2.0, Gewichte modifizierte OpenRAIL-M mit Umsatzschwelle 5 Mio. USD Hardware: GPU empfohlen
Stärken: Kompakt, gutes Kosten-Genauigkeits-Verhältnis, 90+ Sprachen, layoutbewusste Ausgabe in einem Durchgang. Schwächen: Gewichte-Lizenz separat prüfen bei Umsatz über 5 Mio. USD. Jünger und weniger etabliert als Tesseract/PaddleOCR. Am besten für: Layout-Analyse und OCR in einem Schritt, wenn Lizenzschwelle unproblematisch ist.
GOT-OCR2 (StepFun)
Ansatz: Kompaktes, spezialisiertes OCR-Modell (~580 M Parameter) Lizenz: Apache-2.0 Hardware: Ein einzelnes GPU-Modell ausreichend
Stärken: Gute Leistung bei Fließtext, Formeln, Tabellen. Sehr permissive Lizenz. Schwächen: Geringere Community-Adoption, weniger Tooling/Ökosystem als PaddleOCR oder MinerU. Am besten für: Schlanke Einzelmodell-Lösung ohne Pipeline-Overhead.
Nach Dokumenttyp
| Dokumenttyp | 1. Wahl | 2. Wahl |
|---|---|---|
| Digitale PDFs (Verträge, DocuSign) | Docling / PyMuPDF-Textlayer | — |
| Saubere Scans, gedruckter Text | PaddleOCR | Tesseract |
| Alte/verschlissene Scans | PaddleOCR-VL | MinerU |
| Formulare/Tabellen | PaddleOCR (PP-Structure) | MinerU |
| Technische Zeichnungen (A0–A2) | PaddleOCR-VL | Docling (bei Textlayer) |
| Wissenschaftliche Dokumente mit Formeln | MinerU | Marker |
| Handschrift | VLM-Ansatz (PaddleOCR-VL) | — |
| Mehrsprachig / CJK | PaddleOCR | Surya |
| RAG/LLM-Ingestion, gemischter Bestand | MinerU + Docling im Zwei-Stufen-Setup | — |
Warum die Reihenfolge: Bei digitalen PDFs kostet ein Textlayer-Zugriff Millisekunden statt Sekunden — kein OCR nötig. Bei Alt-Scans kompensiert der VLM-Ansatz Bildfehler besser als eine klassische Pipeline, Vorverarbeitung (Enhancement) davor ist trotzdem stark empfohlen. Bei Formeln/Tabellen zählt die dedizierte Erkennung (LaTeX/HTML-Ausgabe), nicht reine Texterkennung. Für gemischte Bestände hat sich das Zwei-Stufen-Muster (günstiger Konverter zuerst, schwerer Parser nur bei Bedarf) in der Praxis durchgesetzt.
Lizenz-Stolperfallen
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 eingesetzte Version prüfen.
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
Aus dem GIGA-Document-OCR-Benchmark, August 2026. Referenzdokument: born-digital PDF, 1 Seite.
| Engine | Zeit | Zeichen |
|---|---|---|
| Docling | 4–6 s | 2078 |
| MinerU | 30–70 s | 2028 |
| Marker | 120–180 s | 2124 |
| PaddleOCR-VL | 340–450 s | 2106 |
Docling am schnellsten dank Textlayer-Pfad. MinerU liest leicht konservativer als die anderen. Marker läuft im CPU-Modus mit llama.cpp-Backend. PaddleOCR-VL am langsamsten, aber stabil nach einem Self-Healing-Patch gegen einen internen Worker-Absturz.
Auf einem harten Fall (großformatiger Scan von 1987) 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, da zu aggressive Kontrastanhebung oder Binarisierung blasse Schrift wieder zerstören kann.