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 (GIGA-Document-OCR-Benchmark, Aug. 2026)

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).