Optische Zeichenerkennung kann vollständig in einem Browser-Tab laufen. Auf dieser Seite lädt Bild zu Text die Tesseract.js-Erkennungs-Engine als WebAssembly, liest das Bild aus dem lokalen Speicher und gibt bearbeitbaren Text zurück, sodass das Bild nie übertragen wird. PDF zu Text geht noch weiter und vermeidet die Erkennungs-Engine meist ganz.
Der PDF-Weg ist der interessantere Aufbau. Das Tool durchläuft das Dokument Seite für Seite und liest zuerst eine vorhandene Textebene. Ein digitales PDF, eines, das aus einem Textverarbeitungsprogramm oder einem Design-Tool exportiert wurde, liefert exakten Text in etwa einer Sekunde und lädt die Erkennungs-Engine überhaupt nicht herunter. Nur Seiten mit praktisch keinem Text, also Scans und Fotos, werden in doppelter Größe gerendert und an OCR übergeben. Dieser zweistufige Ansatz bedeutet, dass der große Download nur bezahlt wird, wenn er wirklich nötig ist, und gescannte Seiten werden einzeln mit ein paar Sekunden pro Seite abgearbeitet.
Der Grund, warum das wichtig ist, ist nicht abstrakt. Gescannte Dokumente sind die Kategorie, die Menschen am ungernsten aushändigen: unterschriebene Formulare, Arztbriefe, Rechnungen, Ausweispapiere, alles, was am Schreibtisch fotografiert wird. Eine Erkennungs-Engine, die lokal läuft, nimmt die Entscheidung ganz ab, weil es keine Kopie gibt, über die man nachdenken müsste.
Bild zu Text
Lies den Text aus einem Foto, einem Screenshot oder einem Scan. Mehrere Bilder werden der Reihe nach verarbeitet, und das Ergebnis landet in einem bearbeitbaren Feld, das du kopieren oder herunterladen kannst.
Was sich ändert, wenn die Erkennung im Browser läuft
Ein serverbasierter OCR-Dienst empfängt deine Datei, führt die Erkennung auf seiner eigenen Hardware aus und gibt den Text zurück. Ein browserbasiertes Tool lädt stattdessen die Engine herunter statt des Dokuments, und der Datenverkehr fließt in die entgegengesetzte Richtung.
| Erkennung im Tab | Erkennung auf einem Server | |
|---|---|---|
| Was über das Netzwerk geht | Engine- und Sprachdateien, in | Dein Dokument, raus |
| Kopien auf der Festplatte eines anderen | Keine | Zumindest der Upload, meist auch eine Ergebnisdatei |
| Konto | Nicht nötig | Oft für Stapel oder größere Dateien erforderlich |
| Funktioniert offline nach dem ersten Laden | Ja | Nein |
| Geschwindigkeit | Ein paar Sekunden pro gescannter Seite | Schneller bei großen Stapeln |
| Von dir überprüfbar | Ja, im Netzwerk-Panel | Nein |
Ein technisches Detail ist erwähnenswert, weil es erklärt, warum dies ohne spezielle Serverkonfiguration möglich ist. Die Engine ist single-threaded und verwendet kein SharedArrayBuffer, daher braucht die Seite nicht die Cross-Origin-Isolation-Header, die mehrthreadiges WebAssembly normalerweise erfordert. Deshalb kann ein einfacher statischer Host sie ausliefern.
Der zweistufige Aufbau von PDF zu Text
Die meisten PDFs, die Leute als Scans bezeichnen, sind überhaupt keine Scans. Ein Dokument, das aus einem Textverarbeitungsprogramm, einer Tabellenkalkulation oder einem Berichtsgenerator exportiert wurde, enthält echte Zeichen, die auf der Seite positioniert, aber als Text gespeichert sind. Diese Zeichen mit OCR zu erkennen, wäre seltsam, weil es Fehler in Daten bringt, die bereits exakt waren.
Stufe eins: die Textebene lesen
Das Tool öffnet das PDF mit PDF.js und fragt jede Seite nach ihrem Textinhalt, dann baut es die Lesereihenfolge aus den Positionsdaten neu auf, damit Zeilen und Absätze in einer sinnvollen Reihenfolge herauskommen. Diese Stufe ist schnell und verlustfrei: Die Zeichen sind die, die die Datei bereits enthält, es kann also nichts schiefgehen. Eine Seite gilt als texthaltig, wenn sie mindestens 20 Nicht-Leerzeichen enthält, was absichtlich niedrig angesetzt ist, damit eine Seite mit einer wirklich kurzen Bildunterschrift trotzdem direkt gelesen wird.
Stufe zwei: nur die Seiten erkennen, die es brauchen
Seiten, die diesen Test nicht bestehen, sind die, die tatsächlich Bilder sind, und sie nehmen einen anderen Weg. Jede wird in doppelter Normalgröße auf ein Canvas gerendert, in ein PNG umgewandelt und an die Erkennungs-Engine übergeben. Die Verdopplung des Render-Maßstabs ist wichtiger, als es klingt, denn OCR-Modelle arbeiten mit Strichen und Kanten, und eine mit Bildschirmauflösung gerasterte Seite verliert die feinen Details im Kleingedruckten.
| Dokument | Was das Tool macht | Engine-Download |
|---|---|---|
| Digitales PDF, alle Seiten enthalten Text | Liest die Textebene auf jeder Seite | Keine |
| Gescanntes PDF, keine Textebene | Rendert jede Seite mit 2x und erkennt sie | Ein Download, danach zwischengespeichert |
| Gemischtes Dokument, gescannter Anhang | Liest Textseiten direkt, erkennt den Rest | Ein Download, für einen Teil der Datei verwendet |
Das Ergebnis verrät dir, welchen Weg jede Seite genommen hat. Die Zusammenfassung meldet die Seitenzahl, wie viele Seiten aus der Textebene kamen und wie viele erkannt wurden, und der Textkörper ist in Seitenblöcke aufgeteilt. Diese Unterscheidung ist in der Praxis nützlich: Wenn ein Dokument, von dem du dachtest, es sei digital, einen Haufen erkannter Seiten meldet, wurde es wahrscheinlich irgendwo unterwegs in ein Bild gedruckt.
PDF zu Text
Digitale Seiten werden in etwa einer Sekunde aus der Textebene gelesen. Die Erkennungs-Engine wird nur für Seiten geladen, die wirklich Bilder sind.
Was die Engine tatsächlich herunterlädt
Beim Laden der Seite wird hier nichts abgerufen. Die Engine kommt bei Bedarf, beim ersten Klick auf die Schaltfläche, und die Zahlen sind erwähnenswert, weil sie sowohl die Verzögerung als auch das anschließende Offline-Verhalten erklären.
- Der Kern umfasst etwa 3,7 MB. Das ist die WebAssembly-Version des Erkennungsmodells, und es ist eine einzelne selbst gehostete Datei statt mehrerer Varianten.
- Die englischen Sprachdaten umfassen etwa 2,8 MB und wird von dieser Seite ausgeliefert, sodass der Normalfall überhaupt keinen Dritten braucht. Zusammen zieht der erste englische Durchlauf etwa 6,5 MB, und der Browser speichert sie zwischen.
- Die anderen Sprachen kommen von einem öffentlichen Tesseract-Daten-CDN. Das Auswahlfeld listet insgesamt zwölf Sprachen auf; Englisch ist lokal, und die übrigen elf, von Chinesisch und Japanisch bis Russisch und Arabisch, werden bei der ersten Nutzung heruntergeladen und von der Engine in IndexedDB zwischengespeichert.
- Es wird immer nur ein Worker gehalten. Ein Worker hält den Kern plus die Sprachdaten im Speicher, daher beendet ein Sprachwechsel den vorherigen, statt sie zu stapeln.
- SIMD-Unterstützung wird geprüft, bevor etwas geladen wird. Der Loader validiert zuerst ein kleines WebAssembly-Beispiel, weil die Engine-Version Vektoranweisungen erfordert. Ohne diese Prüfung würde ein älterer Browser mit einem tiefliegenden Kompilierungsfehler scheitern statt mit einer lesbaren Meldung.
So erhältst du ein sauberes Ergebnis
- Wähle die Sprache, bevor du beginnst. Es ist die einzige Einstellung, die die Genauigkeit entscheidet, und sie gilt nur für Seiten, die durch die Erkennung gehen. Ein digitales PDF ignoriert sie vollständig.
- Sende die schärfste Quelle, die du hast. Das Originalfoto schlägt einen Screenshot einer Vorschau, und ein flacher Scan schlägt eine schräg aufgenommene Handyaufnahme. Wenn du nur ein Foto hast, hilft ein leichtes Zuschneiden auf den Textblock mehr als jede Einstellung.
- Begradige und beleuchte es. Eine um ein paar Grad gedrehte Seite oder eine von einer Seite beleuchtete Seite mit einem Schatten über die Mitte kostet mehr Genauigkeit als eine niedrigere Auflösung.
- Führe es aus und lies die Ausgabe. Das Ergebnisfeld ist bearbeitbar, korrigiere Namen und Zahlen also dort, statt sie später zu exportieren und zu patchen.
- Prüfe den Konfidenzwert. Er wird als Durchschnitt über die Datei angegeben. Ein niedriger Wert ist ein Signal, die Quelle erneut zu prüfen, kein Urteil über den Text.
Wenn ein Foto vor der Erkennung aufbereitet werden muss, Bild-Zuschneider und Bild-Kompressor beide laufen lokal, sodass die ganze Kette vom Rohfoto bis zum Text auf dem Gerät bleiben kann.
Wo OCR weiterhin scheitert
Klarheit darüber ist nützlicher als eine Zuverlässigkeitsaussage, denn die Fehlerarten sind vorhersehbar und hängen eher damit zusammen, wie die Quelle erstellt wurde, als mit der Engine.
- Design-Grafiken und farbige Hintergründe. Das Erkennungsmodell wurde auf Dokumenten trainiert, nicht auf Postern. Getestet an der eigenen dunkelblauen Cover-Grafik dieser Website, die große stilisierte Schrift enthält, gab die Engine nur einen einzigen Bindestrich zurück. Jedes Bild, in dem Text dekorativ statt gesetzt ist, ist ein schlechter Kandidat.
- Handschrift. Gedruckter Text ist das Ziel. Handschriftliche Notizen, Unterschriften und Formulareinträge liefern unzuverlässige Ergebnisse, und keine Auflösung behebt das.
- Schlechte Scans. Schwache Thermobelege, Faxe, Fotokopien von Fotokopien, im Scanner schief eingezogene Seiten. Die Genauigkeit sinkt mit jedem dieser Fälle, und das Tool kann dich nicht davor warnen, welche Wörter zweifelhaft sind.
- Geschwindigkeit bei gescannten Seiten. Die Erkennung dauert ein paar Sekunden pro Seite, und die Arbeit findet auf deiner eigenen CPU statt, sodass der Tab währenddessen beschäftigt ist. Ein langes gescanntes Dokument ist eine langsame Aufgabe, keine sofortige.
- Sprachabdeckung. Nur die zwölf Sprachen im Auswahlfeld. Alles andere wird nicht unterstützt, und eine Seite, die zwei Schriften mischt, wird mit dem einen von dir gewählten Modell gelesen, was Genauigkeit bei der zweiten kostet.
- Das Layout bleibt nicht erhalten. Die Ausgabe ist reiner Text mit Seitenmarkierungen. Spalten, Tabellen und Seitenleisten kommen als linearer Fluss heraus, sodass ein komplexes Layout danach neu formatiert werden muss.
- Passwortgeschützte PDFs müssen zuerst entsperrt werden. Der Reader kann eine verschlüsselte Datei nicht öffnen, und das Tool sagt das, statt stillschweigend zu scheitern.
Wann ein serverbasierter Dienst die bessere Antwort ist
Lokale Erkennung ist die richtige Standardwahl für eine Handvoll Dokumente und das falsche Tool für einige konkrete Aufgaben. Dreihundert gescannte Rechnungen, ein Archiv mit viel Handschrift, eine Schrift außerhalb der unterstützten Liste oder die Anforderung einer strukturierten Ausgabe, die die Tabellengeometrie erhält, weisen alle in dieselbe Richtung, denn dafür braucht es Durchsatz oder Modelle, die eine Browser-Version nicht mitbringt.
Die nützliche Gewohnheit ist, die beiden Fälle vor dem Start zu trennen. Wenn das Dokument sensibel und die Menge klein ist, deckt der Browser-Weg es ab und die Datei bewegt sich nie. Wenn die Menge groß ist, ist der richtige Schritt ein genehmigter Dienst statt hundert manueller Durchläufe, und die Entscheidung darüber, welcher Dienst, ist eine organisatorische und keine technische. Diese Trennung und ihre Anwendung auf Teams, die Personal-, Rechts- oder Klinikunterlagen bearbeiten, ist das Thema von sensible Dokumente und die Cloud.