Original dataset · 8 fixtures · 10 measured runs

OCR accuracy challenge: DPI, skew, rotation, noise, and language

How accurate is browser OCR on a clean scan, a 100 DPI page, faded ink, noise, skew, sideways text, and accented Spanish or German? We published every input, ground-truth file, extracted output, formula, and checksum.

Executive Summary

Orientation was the decisive failure mode. Correcting a sideways page raised measured character accuracy from 8.08% to 97.60%.

With the recommended language and an upright page, all eight synthetic fixtures reached 96.98–97.76% character accuracy. The ambiguous character line (0 O 1 I 5 S 8 B) caused most remaining errors. Spanish with the English model fell from 97.76% to 94.40%, especially on accents, opening punctuation, and ñ.

  • Fix orientation first: sideways text produced 0% word accuracy until the new 90° correction was applied.
  • Choose the document language: the correct Spanish model reduced character edits from 20 to 8 on the same page.
  • Do not assume 300 DPI guarantees perfection: the clean 300 DPI fixture still confused tightly spaced lookalike characters.
  • Proofread identifiers: skew split the exact marker and reference code even though overall character accuracy remained 97.27%.

Run private browser OCR Download all challenge fixtures

Measured character accuracy

Character accuracy is max(0, 1 − character edits ÷ ground-truth characters) × 100 after Unicode NFC normalization and whitespace collapsing. Values are direct-labeled; the table supplies every exact field.

Source: GoPDFConverter OCR Accuracy Challenge CSV, production build v89, Chrome, July 10, 2026. Runtime is recorded for reproducibility but is not a speed promise.

All 10 OCR results

Fixture / settingChar. accuracyWord accuracyEdits (char / word)Marker exactConfidenceOutput
Clean 300 DPI · English97.28%84.62%9 / 8Yes91Text
Low resolution 100 DPI · English97.59%84.62%8 / 8Yes93Text
Faded 300 DPI · English97.28%84.62%9 / 8Yes91Text
Noise + blur · English96.98%82.69%10 / 9Yes90Text
3° skew · English97.27%76.92%9 / 12No90Text
Sideways · no correction8.08%0.00%307 / 149No44Text
Sideways · rotate 90°97.60%84.62%8 / 8Yes92Text
Spanish · Spanish model97.76%84.48%8 / 9Yes91Text
Spanish · English model94.40%72.41%20 / 16Yes87Text
German · German model97.35%84.62%9 / 8Yes93Text

Download every measured field as CSV

Recommended settings

What you seeWhat to do firstWhy
Text is sideways or upside downUse Page orientation before OCROrientation correction changed the test from unusable to 97.60% character accuracy.
Spanish, French, German, Portuguese, or ItalianSelect the matching languageThe wrong model damaged accents, opening punctuation, and language-specific letters.
Serials, invoice codes, or IDsProofread every identifierLookalike characters and skew split exact tokens even when paragraph accuracy stayed high.
Faded or noisy scanTry OCR, then inspect low-confidence linesThese fixtures stayed readable, but real stains, handwriting, and compression can be harder.
Digital PDF with selectable textUse PDF to Text, not OCRDirect extraction is faster and preserves the existing text layer without recognition errors.

Download the challenge set

Every PDF is one image-only Letter page; Poppler text extraction returns no hidden text. The set is deterministic, contains no personal data, and is licensed CC BY 4.0.

FixturePDFGround truthSource DPI
Clean EnglishPDFTXT300
Low-resolution EnglishPDFTXT100
Faded EnglishPDFTXT300
Noisy EnglishPDFTXT200
Skewed EnglishPDFTXT200
Sideways EnglishPDFTXT200
Spanish accentsPDFTXT200
German umlautsPDFTXT200

Fixture manifest and SHA-256 checksums · Download all PDFs and ground truth

Method

  1. Generate controlled, image-only PDFs.

    Pillow and ReportLab created eight deterministic Letter-size PDFs. Conditions isolate source DPI, contrast, Gaussian noise and blur, 3° skew, 90° rotation, Spanish accents, and German umlauts.

  2. Run the production browser pipeline.

    Chrome executed the same PDF.js page renderer, 200 DPI setting, Tesseract.js 5.0.4 engine, language selection, and orientation correction used by OCR PDF.

  3. Score outside the OCR code.

    A separate Python script normalized Unicode to NFC, collapsed whitespace, and calculated Levenshtein edits over characters and whitespace-delimited tokens. It also checked each unique marker as an exact substring.

  4. Keep the evidence inspectable.

    The CSV includes settings, exact denominators, confidence, observed runtime, fixture checksums, and extracted-text checksums. Raw text and ground truth are linked above.

  5. Trace browser requests.

    The test observed local PDF requests, PDF.js and Tesseract library delivery from jsDelivr, and local blob workers. The document content was processed from local URLs and browser memory; no request containing an uploaded PDF or extracted text was observed.

Caveats and assumptions

This is a controlled synthetic challenge, not a population estimate for every scan. The pages use one sans-serif print font and short blocks of text; they do not cover handwriting, columns, tables, mixed scripts, historic type, stamps, severe perspective distortion, or damaged documents. The 100 DPI case uses relatively large 14-point source text and should not be read as proof that all 100 DPI scans are sufficient.

Word accuracy here is an intentionally strict whitespace-token comparison. One missing space in 0 O 1 I 5 S 8 B can count as several word edits even when most paragraph text is correct. Tesseract confidence is the engine’s own estimate, not a calibrated probability. Runtime depends on the device, cache, browser state, and thermal conditions.

Next steps

Further questions