Offline OCR & Document Redactor Reference

What Is OCR (Optical Character Recognition)?

OCR stands for optical character recognition. Software analyzes pixel patterns in a raster image and identifies printed or handwritten characters, converting them into machine-editable text. The output is a string of characters rather than the original image pixels, enabling text search, copy-paste, and downstream processing on content that was previously locked inside an image file.

What is OCR?

How OCR engines process images

Modern OCR engines such as Tesseract 5 use an LSTM neural network trained on large corpora of printed and handwritten text.¹ Input image preprocessing includes deskew, binarization (converting to black and white), and noise removal. The binarized image passes to the LSTM layer, which predicts character sequences using a connectionist temporal classification approach. Recognized characters are then assembled into words using a dictionary and language model. Consequently, OCR accuracy depends on both image quality (contrast, resolution, noise) and the match between the training data and the font style in the image. Standard printed text in common fonts achieves 95 to 99 percent character accuracy at 300 DPI.²

What affects OCR accuracy

Resolution is the primary quality factor: 300 DPI provides enough pixels per character for reliable recognition of most printed fonts at 10 points and above.² Below 150 DPI, small characters merge or break, causing misidentification. Contrast between ink and background affects binarization quality; low-contrast documents (faded ink, colored paper) produce noisier binarized images with more recognition errors. Building on this, document skew and page curl distort character shapes; a 5-degree rotation reduces accuracy measurably on some engines. Font type also matters: serif and sans-serif standard fonts achieve higher accuracy than decorative, handwritten, or specialized technical fonts. Paper texture and background patterns add noise that the binarization step must overcome, which is why clean white paper with dark ink produces the most reliable results.

OCR in browser applications with WebAssembly

Tesseract compiles to WebAssembly (WASM), enabling OCR to run entirely in the browser without any server upload. The WASM binary executes in a Web Worker thread, keeping the UI responsive during recognition. Language data files download once and cache locally; the compressed English training data is approximately 2 MB for the browser build. Subsequent sessions use the cached binary and data files, enabling offline OCR. Furthermore, browser-based OCR using Tesseract WASM achieves recognition accuracy equivalent to the native binary because the WASM compilation preserves the full LSTM inference logic without approximation.³ The key advantage for document redaction is that your files never leave the browser, eliminating the privacy risk inherent in cloud-based OCR services that require uploading documents to remote servers.

OCR output formats: text strings, bounding boxes, and confidence scores

OCR engines return more than raw text. Tesseract 5 produces a structured result containing the recognized text, a confidence score between 0 and 100 for each recognized word, and bounding box coordinates specifying the pixel location of every character, word, line, and paragraph in the image.⁴ Each bounding box consists of four values: the x and y coordinates of the top-left corner, and the width and height of the rectangle. These coordinates allow downstream applications to locate any recognized element precisely within the source image.

Bounding box data is the foundation of word-aware document redaction. When you draw a rectangle over a name in the OCR Redactor, the tool compares your rectangle's pixel bounds against every word's bounding box and removes words whose boxes overlap yours. Without bounding box data, a redaction tool can only cover pixels visually; it cannot simultaneously remove the corresponding text from the exported text file. Consequently, any redaction workflow that needs to produce a clean text export alongside the visual redaction requires an OCR engine that returns bounding box coordinates alongside recognized characters.

Confidence scores and their role in redaction workflows

Confidence scores indicate how certain the engine is about each recognized word. A score below 60 typically signals a character that the LSTM model could not resolve unambiguously, often due to damaged ink, low contrast, or an unusual font. In automated redaction pipelines that identify target fields by matching text patterns, filtering to words above a confidence threshold of 60 avoids acting on misrecognized text. For manual redaction using the OCR Redactor, the text panel shows all recognized words; low-confidence words may appear garbled, which is a signal to inspect the corresponding image region visually and draw a rectangle based on what you see rather than what the text panel shows.

When building a production redaction pipeline, consider that confidence scores are per-word, not per-character. A multi-word identifier like a full name or address may have some words scored above 60 and others below, causing the automated match to fail on the low-confidence tokens. A practical approach is to expand the search region to include adjacent words above the threshold and apply redaction to the merged bounding box, which captures the full identifier even when individual token confidence varies.

Preprocessing steps that improve OCR accuracy before recognition

Image preprocessing runs before the LSTM layer processes any image. Tesseract applies several preprocessing steps automatically: grayscale conversion collapses color channels to a single luminance channel; Otsu thresholding binarizes the grayscale image by computing a global threshold that separates ink pixels from background pixels; deskew detection estimates and corrects page rotation up to a few degrees; and noise removal eliminates isolated pixel clusters that would otherwise register as character fragments.¹ Each step removes variability that would otherwise produce recognition errors downstream.

You can improve OCR results on difficult scans by preprocessing images yourself before dropping them into the tool. Increasing contrast using any image editor makes the binarization step cleaner on faded documents. Cropping to remove large blank margins reduces the area the layout analysis algorithm must examine, which speeds up processing and sometimes improves reading order. Converting a color scan to grayscale before submission has a smaller effect than contrast improvement, because Tesseract performs the grayscale conversion internally regardless.

When to apply manual image enhancement

Manual enhancement is worth doing when OCR output on the raw scan misses 5 percent or more of visible words. Common candidates include: documents scanned through a glass plate with background reflections, photocopies of photocopies with accumulated noise, forms with colored background grids that binarize as dark rectangles, and documents photographed under uneven lighting that creates a brightness gradient across the page. Adjusting levels to bring the darkest background to near-white and the lightest ink to near-black before submitting the image resolves most of these cases. After enhancement, the binarization threshold lands on a clean boundary between ink and paper, and character recognition accuracy improves measurably.

Multi-language OCR and character whitelist configuration

Tesseract supports over 100 languages, each requiring a separate traineddata file.⁵ The language selected at initialization determines which character repertoire and statistical model the LSTM layer applies during recognition. Choosing the wrong language for a document degrades accuracy significantly: running English-only recognition on a French document with accented characters produces garbled output for any character outside the ASCII range. For documents mixing two languages, Tesseract accepts a combined language specification such as "eng+fra" that loads both models simultaneously and applies the combined character set and probability distribution.

Character whitelist configuration is a separate optimization for documents with a known limited character set. A numeric-only invoice, a serial-number label containing only uppercase letters and digits, or a form with fixed alphanumeric fields all benefit from restricting recognition to the relevant characters. With a whitelist active, Tesseract rejects any character outside the specified set, which eliminates false positives from noise pixels that might otherwise score as punctuation or rare letters. The OCR Redactor uses default English language data without whitelist restrictions, making it suitable for general-purpose document processing where character set is unknown in advance.

Selecting the right language data file for accuracy

Tesseract ships with three tiers of English training data: fast (from tessdata_fast, approximately 1 MB compressed for browser delivery), standard (from tessdata, approximately 23 MB including both legacy and LSTM models), and best (from tessdata_best, approximately 15 MB with float LSTM weights).⁶ The best model applies a more complex LSTM configuration trained on a wider corpus and produces higher accuracy on difficult documents at the cost of longer processing time. For the browser WASM build, the fast model balances accuracy and download size. When processing scans with non-standard fonts, technical symbols, or degraded source material, switching to the best model produces measurably better results, particularly on characters with ambiguous stroke shapes.

Try in the tool

What Is Document Redaction?

Document redaction permanently removes information from a record. The goal is to produce a version of the document that can be shared with parties who should not see the removed content, while preserving the rest of the document's usefulness. Proper redaction removes content from the document structure entirely, not merely obscures it from view.

What is document redaction?

Types of document redaction

Physical redaction on paper uses opaque tape or black marker to cover content, then photocopies the result to prevent the original from showing through. Digital redaction falls into two types: cosmetic and structural. Cosmetic redaction draws a black rectangle on top of content in a PDF or image viewer without modifying the underlying data; this type fails under basic technical scrutiny.

Structural redaction and raster export

Structural redaction removes content from the document file structure so it cannot be recovered. Raster redaction, which exports a flat image with no text layer, achieves structural removal for image documents. Building on this, PDF content stream redaction using tools like PyMuPDF's apply_redactions() achieves structural removal for native PDF documents.¹ CapyToolkit's OCR Redactor uses the raster export approach, producing PNG files with no underlying text layer to extract. Raster export is the simpler path and is appropriate when the redacted document will be viewed or printed but not searched or indexed, while structural PDF redaction preserves searchability and accessibility in the non-redacted portions.

When choosing between raster and structural PDF redaction for a production workflow, consider the downstream recipient's tooling and requirements. Legal reviewers who need to search non-redacted portions benefit from structural redaction's preserved text layer. Regulatory submissions that must remain searchable in government archives also require structural PDF redaction. For one-time disclosures, FOIA responses, or public record releases where the recipient will only view or print the document, raster export is sufficient and eliminates the risk of improperly applied structural redaction leaving recoverable content.

Why visual-only redaction fails

Adding a black rectangle to a PDF leaves the text in the PDF content stream. Any PDF parser, text editor copy-paste function, or accessibility tool can extract the covered text in seconds. Documented court cases and government agency disclosures produced improperly redacted documents where opposing counsel recovered sensitive content this way. Consequently, visual-only redaction provides no meaningful protection for digital documents. The test is simple: open the supposedly redacted PDF, press Ctrl+A to select all, then Ctrl+C to copy. If the redacted text appears in the clipboard, the redaction is visual-only and the content is exposed. This failure mode has affected government agencies, law firms, and corporations alike, and it persists because many PDF editors default to cosmetic markup rather than structural content removal.

Redaction standards in legal and regulatory contexts

Federal court rules (FRCP Rule 5.2) require redaction of specific identifiers in electronically filed documents.² HIPAA de-identification standards require removal of 18 identifiers from health information before it can be shared without patient authorization.³ GDPR data minimization principles require limiting shared personal data to the minimum necessary for the purpose.⁴ All three frameworks implicitly require structural redaction rather than cosmetic redaction because visual-only coverage does not prevent recovery of the underlying data. Furthermore, export control regulations, attorney-client privilege rules, and classified information handling standards all require redaction methods that prevent technical recovery of the removed content. Each framework specifies different identifier categories, so the redaction scope for a court filing differs from the scope for a HIPAA de-identification or a GDPR data export.

How courts assess the adequacy of redaction in filed documents

Courts that receive improperly redacted documents can impose sanctions on the filing party, order corrective re-filing at the party's expense, or in serious cases refer the matter for disciplinary review. Federal court local rules in many districts specify that the clerk's office will reject electronically filed documents where obvious redaction failures are visible, such as black rectangles over text in PDFs where the text remains selectable. The filing party bears responsibility for verifying that redaction is complete before submission; the clerk does not independently verify redaction completeness.

Judges reviewing redaction disputes examine whether the method used was technically adequate and whether the scope of redaction was proportionate to the asserted privilege or exemption. A raster export from the OCR Redactor satisfies the technical adequacy standard because no text layer exists to extract. Scope adequacy is a separate question the court decides based on the redaction log and in camera review of the unredacted original. Consequently, technical and scope adequacy are independent dimensions: a technically sound method applied too broadly or too narrowly still produces a legally vulnerable redacted document.

Maintaining a redaction log alongside the exported document

A redaction log records every field covered in a redacted document, the basis for each redaction, and the date of redaction. In legal contexts, privilege logs accompany redacted discovery productions and identify each covered item by document date, author, recipient, subject, and privilege asserted. In regulatory contexts such as HIPAA and FOIA, equivalent documentation supports audit and appeal processes. The OCR Redactor does not generate a log automatically; maintain a separate spreadsheet or document for each redaction session, noting the exported filename, the fields redacted, and the legal or compliance basis for each.

Redaction scope errors: over-redaction and under-redaction

Over-redaction occurs when a party covers more content than the applicable privilege or exemption permits. Courts routinely order re-production of over-redacted documents and may draw adverse inferences about the relevance of improperly withheld content. In FOIA contexts, over-redaction is one of the most common grounds for requester appeals and judicial review; agencies must provide "reasonably segregable" non-exempt portions of otherwise exempt documents.⁵ Drawing redaction rectangles over non-sensitive boilerplate text, headings, or publicly available information constitutes over-redaction regardless of the technical quality of the redaction method.

Under-redaction is the more dangerous error. Missing a single occurrence of a sensitive identifier in a multi-page document can expose the entire piece of information you intended to protect. OCR-guided redaction reduces under-redaction risk by identifying all text instances in the image, but OCR is not perfect. Handwritten notes, stamps, faint ink, and very small fonts can evade detection. Visual inspection of the exported image against the original remains the only reliable completeness check after OCR-assisted redaction.

Applying the minimum-necessary standard to redaction scope decisions

HIPAA's minimum-necessary standard requires covered entities to make reasonable efforts to limit PHI disclosure to what is necessary for the stated purpose.³ Similar proportionality principles appear in GDPR's data minimization requirement and in attorney-client privilege waiver doctrine, which limits waivers to the content actually placed in issue. For practical redaction decisions, the minimum-necessary standard means asking what specific data elements the recipient legitimately needs, then redacting everything else rather than starting from a blank slate and deciding what to add. This narrowing approach produces defensible scope decisions and avoids inadvertent over-disclosure of information outside the stated purpose.

Physical vs digital redaction and when each applies

Physical redaction using opaque tape or marker on a paper original, followed by photocopying, predates digital document processing and remains valid in some contexts. Courts that accept paper filings still use physical redaction for certain exhibit types. The photocopied result contains only the visible content because the physical barrier prevents the copy machine from capturing the covered text. Scanning a physically redacted photocopy produces a raster image equivalent to what the OCR Redactor exports: pixels with no underlying text layer.

Digital redaction applies to documents that exist or are produced in digital form. Native digital documents (word processor files, PDFs with a text layer) require structural redaction that removes content from the file's data structure. Scanned image files (JPEG, PNG, TIFF) and image-only PDFs require visual raster redaction, because no text layer exists to remove structurally. The OCR Redactor addresses the scanned image case by combining OCR output with visual rectangle drawing, producing raster exports where the redacted content is absent at both the pixel and text levels simultaneously.

Raster export is the simpler path and is appropriate when the redacted document will be viewed or printed but not searched or indexed. Structural PDF redaction using tools such as PyMuPDF's apply_redactions() preserves PDF functionality (searchability, accessibility, copy-paste) in the non-redacted portions while removing the targeted content from the file structure.¹ The choice depends on downstream use: if the recipient needs to search or copy non-redacted text, structural PDF redaction preserves that capability. If the document will only be reviewed visually, raster export is equally effective and eliminates the risk of improperly applied structural redaction.

Try in the tool

What Is Tesseract OCR?

Tesseract is the most widely deployed open-source OCR engine. Originally developed by Hewlett-Packard in the 1980s and open sourced by HP in 2005¹, Tesseract powers OCR features in thousands of applications, cloud services, and developer tools. Its LSTM neural network architecture, introduced in Tesseract 4, achieves recognition accuracy competitive with commercial OCR engines on standard printed text.

What is Tesseract OCR?

Tesseract architecture: from pixel to text

Tesseract 5 uses an LSTM network trained on synthetic and real text in over 100 languages.¹ Input images undergo preprocessing: grayscale conversion, binarization via Otsu thresholding, deskew, and border removal.² The binarized image passes to the LSTM layer, which predicts character sequences using connectionist temporal classification without requiring explicit character segmentation.³ A language model post-processes the LSTM output to apply word-level corrections using a dictionary. Consequently, Tesseract performs better on common words than on proper nouns, technical abbreviations, or content outside its training distribution. Accuracy on clean 300 DPI printed text in English typically exceeds 97 percent at the word level.

Tesseract WASM: running OCR in the browser

Tesseract compiles to WebAssembly via the Emscripten toolchain, producing a .wasm binary that any modern browser can execute. The Tesseract.js project provides the JavaScript wrapper and worker infrastructure that loads the WASM binary in a Web Worker, allowing OCR to run without blocking the browser's main thread.⁴ Language data files (traineddata) download separately and cache in the browser via the Cache API. Building on this infrastructure, browser-based OCR achieves accuracy identical to the native Tesseract binary because the WASM compilation preserves the full computation without approximation. The OCR Redactor uses Tesseract WASM as its recognition engine. Running in a Web Worker also means that heavy OCR processing on a large document does not freeze the browser tab or prevent you from interacting with other pages.

Tesseract language support and training data

Tesseract ships with trained data for over 100 languages. Each language requires a separate traineddata file. The English file (eng.traineddata) is approximately 23 MB for the standard model (which includes legacy and LSTM data) or 15 MB for the best-accuracy model from tessdata_best.⁵ Language files for Chinese, Arabic, and Devanagari are larger because of the extended character sets they cover. Furthermore, Tesseract supports user-defined character whitelists via configuration, which restricts recognition to only the specified characters and can improve accuracy when the document is known to contain only digits and uppercase letters, for example. Custom trained data can be generated using the Tesseract training pipeline for specialized fonts or domain-specific text.

Tesseract preprocessing: binarization, deskew, and noise removal

Before the LSTM layer processes any image, Tesseract applies a preprocessing pipeline that converts the source image into a form optimized for character recognition. Grayscale conversion collapses RGB channels into a single luminance value per pixel, discarding color information that provides no benefit for shape recognition. Otsu's method then computes a global binarization threshold: a single pixel intensity value that best separates the foreground ink from the background paper across the entire image.² Pixels darker than the threshold become black; pixels lighter become white. This binarized image removes tonal variation and isolates character shapes for the neural network.

A skewed image significantly reduces line segmentation quality. Tesseract compensates for mild skew by finding local baselines during recognition rather than rotating the image, which means preprocessing the image to correct skew externally produces better results on tilted scans. A scan rotated more than a few degrees causes Tesseract's line segmentation algorithm to misidentify separate lines as a single long line, producing concatenated words that the language model cannot correct.

Noise removal and its limits

Noise removal eliminates isolated pixel clusters smaller than a minimum connected-component size threshold. Specks, dust artifacts, and paper grain all produce small connected components that would otherwise register as punctuation marks or character fragments. Tesseract removes these before passing the binarized image to the LSTM layer, which reduces false detections on scanned documents with textured paper stock. However, heavy noise from badly degraded originals, microfilm artifacts, or halftone printing patterns can produce clusters large enough to survive noise removal and confuse character segmentation. For heavily degraded originals, manual preprocessing in an image editor produces better results than relying on Tesseract's automatic pipeline alone.

When processing documents with halftone patterns from offset printing or newspaper scans, the noise removal threshold may need adjustment because the regular halftone dots can survive the default connected-component filter and be misinterpreted as punctuation or diacritical marks. A practical workaround is to apply a mild Gaussian blur before OCR to soften the halftone pattern, then let Tesseract's binarization handle the thresholding, which often resolves the false detection issue without manual parameter tuning.

Tesseract configuration: page segmentation modes and output types

Tesseract's page segmentation mode (PSM) setting controls how the engine analyzes the image layout before recognizing characters. The default mode (PSM 3) assumes a fully automatic page layout analysis covering multiple columns, mixed text and image content, and complex layouts. PSM 6 assumes a single uniform block of text, which is faster and more reliable for cropped text regions or single-column documents. PSM 7 treats the entire image as a single text line, useful for address label extractions, form field captures, or narrow banner images. PSM 10 processes the image as a single character, which is appropriate for digit recognition in isolated form fields.

Choosing the wrong PSM for a document type is a common source of accuracy problems. Running PSM 3 on a single-field text region causes the layout analyzer to spend time on column detection that yields no improvement, and sometimes misidentifies the single text block as a two-column layout. Running PSM 6 on a genuinely multi-column document concatenates columns into a single garbled text stream. For the OCR Redactor's general-purpose workflow, the default PSM 3 handles most document types correctly. Developers building custom Tesseract.js integrations should experiment with PSM settings on representative document samples and select the mode that produces the cleanest output for their specific document type.

Output levels: character, word, line, paragraph, and block

Tesseract returns recognition results at five hierarchical levels: symbol (character), word, line, paragraph, and block. Each level corresponds to a different structural unit in the page layout analysis. For redaction workflows, the word level is the most useful because it provides bounding boxes small enough to cover individual identifiers without covering entire paragraphs. For text extraction workflows, the line or paragraph level often produces cleaner results because it aggregates word-level noise into coherent reading units. The block level identifies major content regions such as columns, captions, and headers, which is useful for document classification tasks that need to distinguish header content from body text before deciding which regions to extract or redact.

Tesseract.js versioning and the difference from native Tesseract

Tesseract.js is the JavaScript and WebAssembly packaging of the Tesseract C++ engine. Version numbers in Tesseract.js track the underlying C++ engine release with a JavaScript wrapper version alongside. Tesseract.js 6.x wraps Tesseract 5.x, meaning the recognition accuracy, language support, and PSM behavior match the native Tesseract 5 binary. Differences between the WASM build and the native binary are limited to startup time (WASM initialization is slower due to binary loading), threading (WASM is single-threaded in its default configuration), and memory ceiling (browsers impose memory limits that native binaries do not face).

For the OCR Redactor workflow, the WASM limitations do not affect recognition quality on standard documents. Processing time for a letter-size 300 DPI JPEG scan in the browser is typically 2 to 5 seconds, compared to under 1 second for the same file on native Tesseract 5 with a modern CPU. The accuracy of the recognition result is identical because the same trained model and LSTM inference logic execute in both environments. Memory limits become relevant for very high-resolution scans (600 DPI letter-size images exceed 25 MB uncompressed), which is why the OCR Redactor caps accepted file size at 20 MB.

Keeping language data files current for best accuracy

Tesseract's training data files update independently from the Tesseract engine itself. The tessdata repository on GitHub publishes improved training files when accuracy improvements are validated on benchmark datasets. The best-quality English training data file improves over time as the training team adds more diverse font samples and document types. For the browser WASM build, Tesseract.js bundles a specific language data version with each release; updating to a newer Tesseract.js version may incorporate improved training data alongside engine updates. For server-side Tesseract deployments, download updated traineddata files directly from the tessdata_best repository rather than relying on package manager versions, which often lag by one or two training data generations.

Try in the tool

OCR Accuracy and DPI: The Resolution Standard for Document Scanning

300 DPI is the minimum for reliable printed-text OCR.¹ Below 150 DPI, characters at standard body text sizes (10 to 12 points) contain too few pixels for consistent recognition. At exactly 300 DPI, a 12-point character is approximately 50 pixels tall, which provides sufficient pixel resolution for most OCR engines to distinguish between similar-looking characters such as "rn" and "m" or "l", "1", and "I".

What is OCR DPI requirements?

How DPI affects character recognition

At 100 DPI, a 12-point character spans approximately 17 pixels in height.³ Many characters in standard serif and sans-serif fonts become ambiguous at this resolution because fine strokes merge or disappear. At 200 DPI, the same character spans 33 pixels, which improves discrimination significantly but still struggles with very similar glyphs or damaged originals.

The 300 DPI standard and AIIM guidelines

At 300 DPI, 50 pixels per character height allows Tesseract's LSTM to distinguish fine stroke differences reliably.¹ Consequently, 300 DPI is the accepted minimum across industry standards including the Association for Information and Image Management (AIIM) guidelines for document digitization. CapyToolkit's OCR Redactor processes images at their native resolution, so starting with a 300 DPI scan gives the engine the best possible input for accurate text extraction and redaction.

In legal e-discovery contexts, the 300 DPI standard is commonly codified in court local rules and production agreements, making it a compliance requirement rather than merely a best practice. Documents scanned below 300 DPI for cost or speed reasons may be challenged during production review if OCR quality is insufficient for text search, and re-scanning at higher resolution after initial production can trigger cost-shifting disputes. Scanning at 300 DPI from the outset avoids this risk and satisfies both technical accuracy needs and procedural requirements in jurisdictions that specify a minimum scanning resolution.

When higher DPI improves accuracy

Scanning at 400 or 600 DPI benefits documents with text smaller than 10 points, highly detailed graphics with embedded text labels, tables with very narrow columns, or documents with fine ruled lines close to text.⁴ Building on this, documents with physical damage such as water stains, coffee rings, or faded ink benefit from higher DPI because more pixels allow noise reduction algorithms to separate damaged areas from ink more accurately. For microfilm scans and archival documents, 400 DPI is a common standard. Yet for standard office documents (letters, contracts, forms) at 10 to 12 point body text, scanning above 300 DPI produces diminishing returns in OCR accuracy while significantly increasing file size.

DPI equivalents for mobile phone and screenshot captures

Mobile phone cameras capture document photos at variable effective DPI depending on camera resolution, capture distance, and output image size. A modern smartphone camera (12 to 48 megapixels) photographing a letter-size page from 30 cm produces an effective resolution of approximately 200 to 300 DPI, sufficient for reliable OCR of standard text.⁵ High-DPI displays (2x Retina, 3x smartphone screens) produce screenshots equivalent to 200+ DPI because the device pixel ratio multiplies the logical CSS pixel dimension. Screenshots from 1x displays at standard 96 DPI equivalent are below the 300 DPI threshold but typically produce acceptable OCR results on screen-rendered fonts due to their high contrast and clean anti-aliasing.

Color mode and its interaction with DPI on accuracy

Color mode and DPI interact in ways that matter for practical scanning decisions. At 300 DPI, Black & White (1-bit binary) mode produces the smallest file size, but Tesseract's internal adaptive binarization typically produces equal or better recognition accuracy when fed Grayscale input because converting to Black & White at scan time discards pixel information that Tesseract's software binarization can leverage.⁴ For standard black ink on white paper, Grayscale at 300 DPI is therefore the safer default: it matches or exceeds the accuracy of hardware-binarized input while preserving tonal detail.

Grayscale at 300 DPI becomes essential when the document contains elements that binarization would eliminate regardless of who performs it: faint pencil annotations, lightly inked stamps, colored backgrounds with text of similar luminance, or highlighted text that any binarization clips to white. In these cases, Grayscale preserves tonal information that Tesseract's software binarization can use to recover detail that would otherwise be lost. Color mode at 300 DPI offers no additional OCR accuracy benefit over Grayscale for text-only documents; its only advantage is preserving colorized content that is itself subject to redaction, such as a red stamp or blue signature.

Scanning speed versus resolution tradeoffs on ADF scanners

Automatic document feeders scan at rated speed only at their lowest supported resolution mode.⁶ An ADF scanner rated at 35 pages per minute typically achieves that speed at 200 DPI in Black & White mode. At 300 DPI, throughput drops by approximately 30 to 50 percent depending on the scanner model and host interface. At 600 DPI, throughput may fall below 10 pages per minute on consumer-grade scanners. For high-volume document processing where OCR accuracy at standard text sizes is the goal, 300 DPI Black & White is the optimal setting because it stays within the reliable accuracy range while minimizing the throughput penalty compared to 600 DPI.

Verifying effective DPI after scanning

Scanner software settings do not always produce the DPI they advertise. Some scanner drivers interpolate lower-resolution captures to report a higher DPI value in the output file metadata. An image generated by interpolating a 150 DPI capture to report 300 DPI in its EXIF metadata contains no more actual detail than the original 150 DPI capture; the interpolation adds pixels but not information. Tesseract reads DPI from image metadata (EXIF, PNG pHYs) via Leptonica and only falls back to estimating resolution from pixel data when metadata is missing, so interpolated images produce the same accuracy as the original lower-resolution capture.

Verify effective resolution by checking the image pixel dimensions against the physical document size. A letter-size page (8.5 x 11 inches) scanned at true 300 DPI produces an image 2550 x 3300 pixels. If your 300 DPI scan produces a smaller pixel count, the scanner interpolated or the driver applied a lower effective resolution. For the OCR Redactor, the practical check is whether the extracted text panel shows accurate recognition of standard body text: if 10-point text is misread consistently, the effective resolution is below 300 DPI regardless of what the EXIF metadata reports.

Recommended DPI settings by document type

Different document types have different practical DPI requirements based on their smallest text element.³ Standard office documents with 11 to 12-point body text work reliably at 300 DPI. Legal documents with 9-point footnotes or exhibit stamps benefit from 400 DPI to preserve those smaller elements. Engineering drawings with dimension annotations below 6 points require 600 DPI for reliable OCR of the dimension values. Microfilmed documents typically need 400 to 600 DPI because the reproduction process reduces the effective character size. Medical forms with pre-printed 8-point label text and handwritten entries in adjacent fields require 400 DPI to distinguish printed from handwritten content reliably during visual review after OCR extraction.

Try in the tool

PDF Redaction vs Deletion: Why Visual-Only Redaction Fails

Visual PDF redaction leaves searchable text intact underneath. The most common mistake in digital document redaction is drawing a black rectangle on a PDF page using a PDF viewer or editor, then sharing the resulting file. The black rectangle is a visual overlay: it sits on top of the PDF rendering but does not remove the underlying text from the PDF's content stream.¹ Any PDF parser can extract the covered text in full.

What is PDF redaction vs deletion?

Why visual-only PDF redaction fails

PDF files store content in a hierarchical structure: page objects contain content streams that list drawing instructions for text, images, and vector graphics. Adding a filled rectangle to a PDF adds a new drawing instruction to the content stream but does not remove existing text instructions. Software that reads the full content stream, including text extractors, accessibility tools, and basic copy-paste functions in PDF viewers, accesses the underlying text directly.

The copy-paste test for visual-only redaction

Pressing Ctrl+A in most PDF readers followed by Ctrl+C copies all text regardless of any visual overlays.² Consequently, every high-profile improperly redacted document case in government, legal, and healthcare contexts involved visual-only redaction applied to PDFs with an underlying text layer. CapyToolkit's OCR Redactor avoids this failure mode entirely by exporting raster images with no text layer to extract. The test takes five seconds to perform and exposes redaction failures that would otherwise go unnoticed until the document is already filed or shared with opposing counsel.

When this test is performed on a properly redacted PDF, the copied text will show gaps or placeholder characters where redacted content was removed. If the redacted strings appear verbatim in the clipboard, the redaction was visual-only. For court filings where the clerk's office performs automated redaction checks, this same test is often the first screening step; documents that fail are rejected before reaching the judge. Running this test before every filing eliminates the most common and most embarrassing redaction failure.

What proper structural redaction removes

Proper structural PDF redaction removes three types of content from the target region: text objects (the character drawing instructions in the content stream), image data (rasterized images within the redacted rectangle), and vector graphics (path drawing instructions). After structural redaction using a tool like PyMuPDF's apply_redactions(), the target region contains only the replacement fill color and no underlying data. Text extractors report empty strings for that region. Building on this, saving the redacted file with PDF cross-reference garbage collection (garbage=4 in PyMuPDF) also removes orphaned objects from the file structure that apply_redactions() may have cut but not yet purged, ensuring no residual content remains in the file bytes.³

Raster export as an alternative to PDF structural redaction

Converting a PDF page to a raster image (JPEG, PNG) and exporting the redacted image as a flat PNG or raster PDF achieves structural redaction by design: no text layer exists in a raster image.¹ This approach trades PDF functionality (text search, copy-paste, accessibility) for a guaranteed absence of any underlying text data. For documents that will only be viewed visually and never require text search, raster export is a simpler and equally effective alternative to PDF structural redaction. Furthermore, raster export eliminates PDF metadata that might carry author names, creation timestamps, or comment history, removing a second category of potential data leakage beyond the visible content.

PDF metadata and comment layers as additional data leakage vectors

PDF files contain multiple layers of content beyond the visible page rendering. Document metadata fields (author, title, subject, keywords, creator application, creation date, modification date) store information about the document's origin and history. XMP metadata provides a separate XML-based metadata layer carrying similar fields in a different encoding. PDF comment annotations, form field data, and embedded file attachments represent additional content layers that are invisible in standard viewing but accessible through PDF parsers and extraction tools. Drawing a black rectangle on a page addresses none of these layers.

Structural redaction tools such as PyMuPDF's apply_redactions() operate on page content streams and do not automatically clear metadata or comment layers. After applying page-level redactions, explicitly clear document metadata using the tool's metadata clearing API (doc.set_metadata({}) in PyMuPDF) and check for embedded annotations using the page annotations iterator.⁴ For court filings and regulatory productions, this metadata hygiene step is as important as the page-level redaction because document metadata frequently carries the original author's name, organization, and creation date even after the page content is scrubbed.

Testing redacted PDF files for residual content before sharing

Testing is the only reliable way to confirm that a redacted PDF contains no recoverable sensitive content. Three tests cover the primary exposure vectors. First, open the PDF in Adobe Reader or any PDF viewer and press Ctrl+A (select all) followed by Ctrl+C; paste into a text editor and search for the strings you redacted. If they appear, the redaction is visual-only. Second, run a PDF text extraction tool (pdftotext from the Poppler utilities⁵, or fitz.open().get_text() in PyMuPDF) on the output file and search the extracted text for target strings. Third, inspect metadata using an EXIF or PDF metadata viewer and confirm no sensitive fields appear in author, title, or custom property fields. Passing all three tests before filing or sharing provides reasonable assurance that the document is properly sanitized.

When deletion is the correct choice instead of redaction

Redaction preserves the non-sensitive portions of a document for legitimate use while removing specific sensitive content. Deletion removes the document or page entirely. Choosing the wrong operation produces the wrong outcome: redacting a document that should have been deleted leaves a partial record in circulation, while deleting a document that should have been redacted destroys content that the recipient had a legitimate right to receive. The decision between redaction and deletion depends on the purpose of the document.

When the only portion of a document with any evidentiary, contractual, or informational value is the sensitive portion itself, deletion is the appropriate action. A document that is entirely privileged (such as a legal memorandum that is fully attorney work product) requires withholding, not redaction, in discovery. When the document contains both protected and non-protected content, redaction of the protected portions allows production of the segregable non-protected content. FOIA imposes a specific "reasonably segregable" standard: agencies must provide non-exempt portions even when part of the document is exempt, making redaction the required action for partially exempt records.⁶

Recovering from improper visual-only redaction already distributed

When a document with improper visual-only redaction has already been shared, the sensitive content must be treated as disclosed. Notify the affected parties, rotate any exposed credentials, and if the document is in litigation, contact opposing counsel and the court immediately under applicable inadvertent disclosure rules. In federal court, FRCP 26(b)(5)(B) provides a procedure for asserting inadvertent disclosure of privileged material after production; prompt notification triggers the claw-back process.⁷ Distributing a corrected raster-redacted version after the fact does not undo the disclosure but demonstrates good-faith remediation and may mitigate consequences depending on the jurisdiction and the sensitivity of the exposed content.

Try in the tool