Install from Microsoft Store
How offline OCR works
Optical character recognition traditionally requires sending your image to a remote server where recognition software runs, which means the file leaves your machine and is processed on infrastructure you do not control. This tool takes a different approach: it loads Tesseract, a widely used open-source OCR engine, as a WebAssembly module that executes directly in your browser. No image data is transmitted anywhere, and the page makes no third-party requests for your document content.12
The first time you use the tool, your browser downloads the Tesseract WASM core files and the English traineddata, then stores them through the browser cache so they can be reused on later sessions. Subsequent loads read those files from cache instead of the network, so the tool starts quickly and can run fully offline once the initial download has finished, as long as the cache has not been cleared.1
A concrete pass through a real TSV row shows what the tool works with.
Scanning a printed line reading Invoice Number: 48291
produces one row per recognized word, each carrying its own left,
top, width, height, and conf fields alongside the
recognized text itself, the exact structure Tesseract's command line
reference documents. Drawing a redaction rectangle over the digits
48291 removes only the word whose bounding box falls inside
that rectangle, leaving Invoice Number: intact in the
exported text file.
The English model and other languages
One boundary deserves a name before you feed the tool anything unusual: it runs the English model, and only the English model. Because the worker initialises Tesseract with the English traineddata and exposes no language selector, every document gets read with English eyes no matter what it actually contains. There is no language switch. A page in Spanish, French, or German falls outside what that model was trained to recognize, and no setting in this tool changes that. Scripts beyond the Latin alphabet, such as Cyrillic, Arabic, or Chinese, sit further still from its vocabulary, so whole lines can fail to register at all.
Tesseract itself is not English-only. Its maintainers publish a separate traineddata file for each of more than a hundred languages, from Spanish to Chinese, and setups that need those languages load the file that matches the document.3 In the browser build here, English is what ships, so the reliable path for a non-English document is a tool configured for that language. One limited middle ground exists: the text panel is editable, so a document that is mostly English with a few foreign names or phrases can be corrected by hand after extraction instead of hunting for another tool for the sake of two stray words.
Reading order and multi-column pages
How does the text panel decide what order the words appear in? It
follows the layout Tesseract detects instead of guessing from pixel
positions. Before recognizing a single character, Tesseract's automatic
layout analysis splits the page into blocks, each block into paragraphs,
and each paragraph into lines, and every word in its TSV output carries
the block_num, par_num, and line_num
it belongs to.4 The tool writes those
blocks out in the order Tesseract reads them, with a blank line between
paragraphs. On a two-column page, you get the whole left column first
and the whole right column after it.
Inside each paragraph, the tool decides whether every line break is a
wrap or a real line ending. Two lines join into one sentence when the
next line's first word would not have fit in the space left on the
current line, both lines start at the paragraph's left edge, and neither
line contains a wide gap between words. When a line ends in a hyphen and
the next line starts with a lowercase letter, the tool drops the hyphen
and rejoins the word, so bil- followed by ling
becomes billing. Receipts and forms behave differently. An
item name with its price pushed to the right edge, a centered address,
or a right-aligned total keeps its own line, so a receipt still reads as
a list of rows instead of one run-on sentence.
Because the output depends on Tesseract's layout analysis, a page that
confuses that analysis produces imperfect text. Columns separated by a
narrow gap can come back as a single block, with each printed row
holding a line from both columns, and a short last line sometimes splits
off into a paragraph of its own. A compound word such as
well-known that happens to break at its hyphen also loses
the hyphen when the tool rejoins it. Since the text panel is editable,
you can fix those spots by hand before downloading. None of this affects
redaction: boxes are positional, so a rectangle over an account number
in the right-hand column replaces exactly the words inside it with block
characters, wherever the text panel lists them.
Document redaction
Redaction is the act of removing sensitive content from a document before it is shared, and doing it well requires more than painting over pixels. A good redaction workflow needs to identify every word in the image, locate the regions that contain confidential information, and strip the underlying text so it cannot be recovered from the exported file. That is what the canvas overlay and the text panel are doing together here.
A naive redaction that only paints black pixels over sensitive text leaves the original characters recoverable in the document layer. This tool avoids that failure mode by computing word bounding boxes from the OCR output and removing any word whose coordinates intersect your rectangle, so the rendered text file and exported PDF contain no trace of the redacted content.
Drawing boxes over the canvas
After extraction, draw opaque black rectangles over any region on the
image canvas. The tool cross-references each rectangle against the word
bounding boxes returned by OCR, replacing only the words whose coordinates
overlap a redaction box so the exported text file and PDF contain no trace
of the covered content. Tesseract's TSV output includes word_num, left,
top, width, height, conf, and text fields, which is what makes that
coordinate comparison reliable even when lines are uneven or the text is
rotated slightly.
Each rectangle can be placed anywhere on the image, and the tool updates the text panel the moment you release the pointer, so you can see exactly which words will be removed before you export. Undo Last and Clear All refresh the panel the same way. Drawing a box slightly larger than the target line ensures the entire bounding box is caught, which avoids leaving partial words visible in the final text file.
There is no find-and-redact in this tool. You draw boxes by position, one rectangle at a time, and nothing searches for a word on your behalf. The text panel is the finding aid: read through the extracted text to locate every instance of the name or number you are removing, then draw a box over each occurrence on the canvas, checking after each one that the block characters replaced the right words. Slower than a search box, yes, but the loop keeps every removal visually confirmed against the actual page before you export anything.
Editing and exporting redactions
Use Undo Last to remove the most recent rectangle, or Clear All to start over from a clean canvas. Redactions are non-destructive during your session because the original image data is held separately from the overlay, so adjusting a box never permanently alters the source pixels. The exported PDF keeps the redacted canvas as an image rather than a searchable text layer, which prevents anyone from recovering the covered words from the downloaded file.
Can someone recover what you covered? Not from the exports. The PNG and the PDF are flat rasters, and the black rectangles overwrite the pixels underneath rather than hide them, so neither file carries recoverable content or a text layer to select and copy from. The text file holds block characters wherever the redacted words were, so pasting it anywhere leaks nothing. What still contains the sensitive content is the original image file on your disk, which this tool never modifies, and the live session itself, which holds everything in browser memory until you close the tab. Share the exports, and apply your own keep-or-destroy policy to the original.
Extracting and redacting in one pass
Running OCR and redaction in the same tool is what ties the text export to the image. Each rectangle you draw blanks the words whose bounding boxes it touches in the text panel at the same moment it blacks out the pixels, so the image and the text never disagree about what was removed. The full workflow, from loading the scan to confirming nothing is recoverable, follows.
OCR and redaction belong in the same workflow. Scanning a document and redacting it in two separate tools creates a gap: you export an image from one tool, open another, and manually mark regions without any text intelligence. The OCR Redactor closes this gap by extracting text first and then using those bounding boxes to determine exactly which words fall inside your drawn rectangle.
Every word whose bounding box overlaps a redaction rectangle disappears from the text panel simultaneously. Drawing a rectangle over a name in the image removes that name from the exported text file automatically, with no manual search-and-delete required. The exported PNG and PDF contain no underlying text layer, so redacted content cannot be recovered by selecting text in a PDF reader.
How OCR and redaction work together
Tesseract OCR produces two outputs: the recognized text and the bounding box coordinates for every word in the image.1 The redaction step uses those coordinates directly. When you draw a rectangle on the image canvas, the tool compares the rectangle's pixel bounds against every word's pixel position and removes any word whose box overlaps yours. This means you never need to search the text panel manually for words you covered on the image.
Ensuring full word coverage with bounding box overlap
Drawing the rectangle slightly larger than the visible text region ensures that words at the edge of a bold heading, which Tesseract sometimes assigns wider bounding boxes than their visible ink suggests, are caught by the overlap check correctly. CapyToolkit uses pixel-level overlap detection rather than center-point inclusion, so even words whose bounding box extends slightly beyond the visible character strokes get covered when your rectangle overlaps any portion of the box.
This overlap approach matters most on dense documents where fields sit close together. CapyToolkit's OCR Redactor highlights the covered words in the text panel as you draw, so you see the bounding box match update live instead of guessing where Tesseract placed each token. Slightly enlarging the rectangle is safer than drawing it tight to the visible ink, because a box that extends beyond the character still gets caught by the overlap check.
Why raster export matters for redaction
Standard PDF redaction tools add a black rectangle on top of visible content but leave the underlying text layer intact.2 Any PDF reader can remove that overlay by selecting the edit or remove redactions function in compatible software, or simply selecting all text and copying it. The OCR Redactor exports a raster image, which is a flat PNG or PDF containing only pixels, with no text layer whatsoever. Consequently, recovering redacted text from the exported file is technically impossible because there is no text layer to extract. This makes raster export the correct output for redacted documents shared with external parties who cannot be trusted to handle an improperly redacted PDF responsibly.
The full OCR redaction workflow step by step
Drop a JPEG, PNG, or WebP image onto the OCR Redactor drop zone. Tesseract begins extraction immediately, and the text appears in the right panel within a few seconds for a typical letter-size page, provided the source scan is at least 300 DPI, which is the resolution Tesseract documentation names as its working baseline3. Review the extracted text to confirm the OCR captured the sensitive fields correctly. Draw redaction rectangles on the image by clicking and dragging over the regions to redact. The text panel updates in real time as each rectangle covers matching word bounding boxes. When all redactions are placed, export using Download PNG for a lossless image, Download PDF for a single-page raster PDF, or Download Text to save the clean version with redacted words replaced by block characters.
Handling multi-word names and compound identifiers in redaction
Tesseract produces word-level bounding boxes, so a two-word name like "Maria Johnson" corresponds to two separate entries in the OCR output. Drawing a rectangle that fully overlaps both words covers both bounding boxes, and both tokens appear as block characters in the text panel. If the rectangle only overlaps the first name, the last name remains visible in the text panel as plain text.
Verifying multi-part identifiers are fully covered
After drawing each rectangle, search the text panel for the identifier you just redacted. If any fragment still appears, the rectangle does not fully cover that token's bounding box and needs expanding, or a second rectangle placed over the remainder. Account numbers, invoice numbers, and case reference numbers can span multiple OCR tokens depending on how Tesseract segmented the line, so always confirm these in the text panel after marking them in the image.
Confirming the exported file has no recoverable text
A PNG exported from the OCR Redactor is a raster image with no embedded text layer. It carries no hidden text in an XML metadata field, an ICC profile comment, or a text chunk. Standard image viewers show only the visual pixel data, and the redacted regions appear as solid black rectangles. The PNG format does not support multiple layers or hidden data channels,4 which makes it inherently safer than PDF for distributing redacted documents where the recipient should not have any technical path to recover the covered content.
Checking PNG metadata with a local inspection tool
If your organization requires metadata verification before distributing redacted images, ExifTool (available at exiftool.org and running entirely locally) can inspect all metadata embedded in a PNG file.5 Running ExifTool with the strip-all flag removes every metadata field, leaving only the pixel data. For most documents, the PNG export from the OCR Redactor contains only standard image metadata such as dimensions and color space, with no readable content from the source document, which is what the OCR-and-redaction PNG export is designed to guarantee. Adding a brief ExifTool pass to your distribution checklist takes under five seconds per file and provides documented evidence that the shared file contains no residual text data or identifying metadata from the original scan.
Use this workflow when you need to produce a redacted copy of a scanned document for sharing, legal filing, or compliance review, particularly when the original is a physical paper document without a digital source.
Redacting a scanned contract before sending to a client
Draw rectangles over party names, signature blocks, and pricing sections. Export the redacted PNG. The client receives a clean image with no hidden text layer and no ability to recover the covered content.
Extracting only the non-sensitive text from a medical record scan
After OCR completes, review the text panel and manually delete sensitive lines before downloading the text file. The image export retains your redaction rectangles covering those regions on the visual layer.
- 1.
tesseract-ocr, "tesseract::BoxWord Class Reference," tesseract-ocr.github.io, accessed June 2026. https://tesseract-ocr.github.io/tessapi/5.x/a02698.html
- 2.
ISO, "Information technology — Security techniques — Specification for digital redaction," ISO/IEC 27038:2014, iso.org, 2014. https://www.iso.org/standard/44382.html
- 3.
W3C, "Portable Network Graphics (PNG) Specification (Third Edition)," w3.org, June 2025. https://www.w3.org/TR/png/
- 4.
Tesseract OCR Documentation, "Improving the Quality of the Output," tesseract-ocr.github.io, accessed June 2026. https://tesseract-ocr.github.io/tessdoc/ImproveQuality.html
- 5.
Phil Harvey, "ExifTool," exiftool.org, accessed June 2026. https://exiftool.org
No. CapyToolkit's OCR Redactor runs entirely in your browser. The image you drop into the tool never leaves your device. Tesseract processes it locally using WebAssembly, and the extracted text and redaction boxes exist only in browser memory during your session. Closing the tab removes everything.
Yes. You can draw redaction rectangles directly on the image canvas without waiting for OCR to complete. The redaction export covers those regions visually. Running OCR first enables the text panel to update automatically as you draw, showing exactly which words each rectangle covers before you export.
JPEG, PNG, and WebP images up to 20 MB. PDF files are not directly supported. Take a screenshot or export a page as an image if your document is in PDF format, then drop the image into the tool.
Open the exported PNG in any image viewer and try to select text. No text selection is possible because the export is a raster image. For the PDF export, open it in a PDF reader and press Ctrl+A to select all. Nothing selects. A standard PDF with a black rectangle drawn over text would produce selectable text on Ctrl+A, which is the vulnerability this tool avoids.
The word is still redacted. The tool uses a simple overlap check: if any portion of a word's bounding box falls inside the rectangle, the whole word becomes block characters in the text panel. The catch is that the bounding box is where Tesseract placed the word, which can sit slightly off the visible ink, so a rectangle that looks like it touches a word can still miss its box. Draw the rectangle slightly larger than the visible text and confirm the block characters appear.
Privacy guarantee
The zero-upload guarantee is unconditional because OCR and redaction run
inside a browser WebWorker that never transmits your image data to any
server. That worker operates in a sandboxed background thread with no
access to the page DOM and no telemetry, logging, or cloud processing of
any kind, so the pixels you load stay on your machine for the entire
session.5
You can confirm this guarantee yourself by loading the page, disconnecting from the network, going offline in your browser's developer tools, and then processing a document to check that nothing is sent over the network. The recognition and redaction steps continue to work without any external connection, which demonstrates that no outside service is involved in reading, storing, or analysing your files.
Redacting documents fully offline
Offline here means more than skipping an upload. After the first visit, the OCR engine and its English model sit in your browser's cache, so a later session can read and redact a scan with the network cable unplugged. What that cache holds, how the session keeps documents in memory only, and how to use the tool on machines that never connect are covered next.
Offline redaction means no file ever leaves your device. Most commercial redaction tools operate as web services: you upload a document, the server processes it, and the redacted file downloads back. Each step transmits document content to third-party infrastructure. An offline browser-based tool avoids every upload by running the entire OCR and redaction pipeline inside your browser using WebAssembly.
The OCR Redactor loads Tesseract WASM once and caches it locally. Every subsequent session runs entirely offline; no network access to your document data occurs at any point. You can verify this by disconnecting your internet connection after the page loads and processing a document. The tool functions identically without connectivity because neither OCR nor redaction requires a server.
How offline processing works technically
WebAssembly allows binary code compiled from C++ to run inside the browser at near-native speed without any browser plugin.1 Tesseract's C++ source code compiles to a .wasm binary that downloads once on first use and stores in the browser cache. Subsequent visits to the OCR Redactor load the WASM binary from the local cache with no re-download. The typical download size for the Tesseract WASM engine plus English language data is approximately 2 megabytes on the first visit, after which the browser serves the cached version without any network cost on subsequent loads.2
WebWorker isolation and local CPU processing
During OCR processing, the JavaScript on the page sends the image data to a browser WebWorker, which runs the Tesseract binary in an isolated thread.3 Consequently, the image data never touches any network interface at any point in the pipeline, and the entire computation runs on your local CPU. CapyToolkit's architecture ensures that no document bytes pass through any external server at any stage of the OCR and redaction workflow. The WebWorker thread model also means that closing the browser tab immediately terminates the worker process and releases all memory allocated by the WASM binary, leaving no residual data on the machine.
Running recognition in a worker also keeps the page interface responsive during long scans. CapyToolkit's OCR Redactor keeps the image rendering and your rectangle drawing on the main thread while the WASM binary does the heavy lifting in the background, so the redaction canvas never freezes mid-document. Because the worker communicates with the page only through copied data, the document bytes stay local and never pass through a socket or external service during the recognition step.
Verifying zero uploads during processing
Open the browser's network panel before dropping a document into the tool. Press F12, click Network, then load the page. After the page finishes loading, drop your document into the drop zone and watch the network panel. No new requests appear during OCR processing, rectangle drawing, or export. The only requests visible in the panel are the initial page load assets: HTML, CSS, JavaScript, and the Tesseract WASM binary. Building on this, you can confirm that the exported file downloads directly to your machine without passing through any server by observing the download source in the browser download manager. It shows a blob URL, not a remote server address.4
When to choose offline over cloud-based redaction
Cloud redaction tools offer convenience features such as batch processing, auto-classification of sensitive fields, and team collaboration workflows. Yet those features come with a fundamental tradeoff: every document uploaded to a cloud service becomes subject to that provider's data retention policies, breach risk, and legal jurisdiction. For regulated industries such as healthcare, law, and finance, any upload of a patient record, privileged communication, or financial statement to a cloud service requires a formal data processing agreement. Offline processing eliminates that exposure by keeping the document inside your own system boundary, making it suitable for regulated contexts without any special configuration.
What "offline" means for a browser-based tool: cache, storage, and memory
Offline operation for a browser-based tool has a specific technical meaning. The Tesseract WASM binary and language data files download once and store in the browser's Cache API storage, which persists across sessions independently of the page being open.5 After the initial download, reloading the OCR Redactor page loads both files from the local cache without any network request, even if the internet connection is severed. Processing starts from the cached state. No document data, image bytes, or extracted text touches any network interface at any point during a session.
Browser storage in this context is distinct from document storage. The Cache API holds only the Tesseract engine files, not any document you process. Documents exist only in RAM during the active browser session: the image object loaded into the canvas, the Tesseract recognition output, and the drawn rectangle data all live in process memory. Closing the browser tab releases all of this memory; nothing persists to disk. Consequently, the OCR Redactor leaves no trace of processed documents in any browser storage location after the session ends.
Offline availability after initial load on different browsers
Safari on iOS and macOS caches WASM binaries via the Service Worker Cache API, but Safari applies eviction policies that may clear cached resources after a period of disuse. If the OCR Redactor page has not been visited for several weeks on Safari, the WASM binary may need to re-download on the next visit. Chrome and Firefox apply less aggressive eviction and retain cached resources for longer periods. For environments where offline operation is required reliably without a guaranteed re-download opportunity, Chrome or Firefox on desktop provide the most dependable offline availability after the initial caching session.
Air-gapped environments and offline redaction without any prior internet access
Air-gapped systems have no internet connection at any time. Loading the OCR Redactor on an air-gapped machine requires a different approach than relying on the Cache API: the tool must be served from a local web server on the same network or from a local file. Self-hosting the OCR Redactor on a local HTTP server makes it accessible within the air-gapped environment to any machine on the same internal network segment. The self-hosted version requires bundling the Tesseract WASM binary and language data alongside the application files, so the browser retrieves them from the local server rather than from any external CDN.
For single-machine air-gapped use, running the OCR Redactor as a static site from a local file path (file:// protocol) works in Chromium-based browsers but not in Safari or Firefox, which apply additional restrictions on WebAssembly execution from file URLs. A minimal local HTTP server such as Python's http.server module or the npx serve command, started from the directory containing the built application files, provides the correct serving context for all browsers.
Using the browser network panel to confirm zero document transmission
Before committing to offline redaction for a sensitive workflow, verify the tool's behavior using the browser's built-in developer tools. Open the Network tab in DevTools (F12) before dropping a document into the OCR Redactor. After the page fully loads, clear the network log in the panel. Then drop the document, wait for OCR to complete, draw a redaction rectangle, and export. Review every request in the network log. Only requests for the initial page load assets should appear; any request that transmits image bytes or text to an external host would appear as a POST or PUT request to a non-localhost domain. The absence of such requests confirms the tool operates as documented.
Use offline redaction when your document contains confidential personal data, trade secrets, legal case details, or health information that must never leave your device or network under any circumstances, and run it through the zero-upload offline OCR workflow to keep every byte local.
Redacting a tax return scan on a shared office network
Load the OCR Redactor, then disconnect from the network. Processing the scan in a fully offline state ensures the document cannot be intercepted regardless of network monitoring conditions.
Preparing a redacted document on a managed corporate device
IT-managed devices often have monitoring software that logs network activity. A fully offline tool leaves no network trace of the document in proxy or firewall logs.
- 1.
WebAssembly, "WebAssembly," webassembly.org, accessed June 2026. https://webassembly.org
- 2.
robertknight, "tesseract-wasm," github.com, accessed June 2026. https://github.com/robertknight/tesseract-wasm
- 3.
Mozilla Developer Network, "Using Web Workers," developer.mozilla.org, accessed June 2026. https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers
- 4.
openJavaScript.info, "Create a client-side download with JavaScript," openjavascript.info, accessed June 2026. https://openjavascript.info/2022/07/25/create-a-client-side-download-with-javascript/
- 5.
Mozilla Developer Network, "Cache," developer.mozilla.org, accessed June 2026. https://developer.mozilla.org/en-US/docs/Web/API/Cache
Yes. CapyToolkit designs the OCR Redactor for offline use after the initial load. The first visit downloads the Tesseract WASM binary (roughly 10 MB). After that, every subsequent session runs entirely local with no internet connection required. No account or login is needed.
No. The image and extracted text exist only in browser memory (RAM) during your session. Closing the tab clears both. The OCR Redactor uses no localStorage, IndexedDB, or cookies to persist document data between sessions.
Offline redaction removes the upload risk that makes cloud tools problematic for HIPAA contexts. No business associate agreement is needed because no patient data leaves your device. You remain responsible for securing the exported file according to your organization's HIPAA policies. The tool removes the transmission risk, not the storage risk.
The tool accepts images up to 20 MB. For larger files, reduce the scan DPI (200 DPI produces smaller files than 300 DPI) or compress the image before dropping it in. Most letter-size 300 DPI JPEG scans are well under 5 MB. Files exceeding 20 MB are typically uncompressed TIFFs or very high-DPI PNGs that can be resized without losing OCR-relevant detail.
Network monitoring captures network traffic. Since the OCR Redactor generates no network traffic after the initial page load, documents you process produce no entries in network logs. Conversely, any cloud redaction service generates network traffic logs that may be visible to monitoring software at the firewall or proxy level.
Supported formats
JPEG, PNG, and WebP images are supported up to 20 MB per file, which is
enough for high-resolution scans of multi-page printed documents such as
contracts or medical records. The tool reads each image directly from your
disk through the browser's file picker without uploading it anywhere, so
even large files stay local and process quickly on modern hardware.
PDFs are not directly supported by Tesseract.js, so take a screenshot or export a page as an image first, then process that image through the tool. Multi-page documents require processing one image at a time, which keeps each OCR job small, reduces the chance of a timeout, and lets you review and redact each page individually before exporting. Once every page has been processed, you can save each redacted result as its own PNG or PDF file.
Getting the best results from scanned documents
OCR is only as good as the image you feed it, and the difference between a clean scan and a quick phone photo can be dramatic. Resolution, contrast, skew, and noise all influence how confidently Tesseract can segment lines and recognise characters, so a few minutes of preparation before you upload often pays for itself in fewer recognition errors and less manual correction.
Resolution, contrast, and preprocessing
OCR accuracy depends heavily on input quality. Tesseract performs best on
high-resolution scans with strong contrast between dark text and a light
background. Its documentation recommends images of at least 300 DPI, so
low-resolution captures, poor lighting, and noisy backgrounds can increase
recognition errors. Thin serif strokes, skewed pages, and wide blank
borders also make segmentation harder, so use auto-enhancement, deskew,
and tight cropping before processing.6
Where does a word go when the panel skips it? Every word Tesseract returns carries a confidence value, and this tool silently drops any word scoring under 20 before the text ever reaches the panel.4 A missing word is therefore usually recognized but rejected, not invisible to the engine: the engine saw the word but was not confident enough about what it says. Because blurry edges, low contrast, and small type all push scores down, the same page can extract cleanly at 300 DPI and lose words from a dim photograph. When a critical word is missing, rescan at higher quality instead of retyping from memory.
Why handwritten text is less reliable
Handwritten text is substantially harder for Tesseract than printed text. The English language model bundled with this tool was trained primarily on printed fonts, and recognition accuracy for handwriting varies widely depending on how closely the handwriting resembles printed letterforms. No configuration option improves this without a language model specifically trained on handwriting samples. For printed documents with standard fonts at adequate resolution, recognition accuracy is usually much stronger than for handwriting; photographs of documents can still introduce perspective distortion and uneven lighting that reduce accuracy further, so a flatbed scan is usually the safer starting point.67
Redacting scanned paper documents
A scanner hands you pixels, not words, which is why the OCR step has to come before any redaction that should reach the text export. The quality advice above decides how many words OCR finds, and the steps below cover the rest: preparing the paper before it goes through the scanner, handling multi-page scans, and auditing the exported text for identifiers the rectangles missed.
Scanned documents need OCR before any word-aware redaction can happen. A scanner produces a flat raster image: pixels arranged on a grid with no inherent text meaning. Without OCR, redaction tools can only add black rectangles on top of those pixels visually, with no connection to the underlying content. Running OCR first creates the bounding box map that links image regions to text strings, enabling the redaction layer to simultaneously cover the visual content and remove the corresponding words from the text export.
The OCR Redactor handles this two-step sequence automatically. Drop the scanned image into the tool and OCR runs immediately. By the time you start drawing redaction rectangles, the bounding box data is ready, and each rectangle you draw updates the text panel in real time.
Why OCR quality determines redaction quality
A poorly scanned document produces noisy OCR output with misread characters, missing words, and incorrect bounding box positions. When bounding boxes are inaccurate, drawn rectangles may not perfectly align with the actual word positions in the image. Drawing the rectangle slightly larger than the target text region accounts for bounding box imprecision and ensures the words are caught.
Scanning best practices for reliable bounding box alignment
Consequently, scanning quality is the foundation of the entire workflow. Scan at 300 DPI or higher, use Black & White mode for typed text, and ensure no skew or rotation.1 Rotation and skew are the defects Tesseract documents as its hardest failures to compensate for: quality of line segmentation drops significantly on a skewed page, so straightening the scan matters as much as raising the resolution. A straight, high-contrast scan produces accurate bounding boxes that align precisely with your drawn rectangles. CapyToolkit's overlap detection works best when the OCR bounding boxes accurately reflect the visible text positions, which starts with a clean, well-aligned scan.
Handling multi-page scanned documents
The OCR Redactor processes one image per session. Multi-page scanned documents must be processed as individual page images. Scan the document and save each page as a separate JPEG, or configure your scanner software to save individual pages rather than combining them into a PDF. Drop each page image into the tool, draw redactions, and export the page PNG. After processing all pages, combine the exported PNGs into a single PDF using any local PDF assembly tool, and ImageMagick's command line accepts a filename glob so the whole batch converts in one invocation2. Building on this, pages that contain no sensitive information can be exported directly from your scanner without the redaction step; process only the pages where sensitive content appears to save time.
Verifying completeness of redaction after OCR
After placing all redaction rectangles, review the text panel by searching for the sensitive terms you redacted. If a name, number, or identifier still appears in the text panel, a rectangle does not fully overlap its bounding box. Expand the rectangle or add a second rectangle to cover the remaining portion. Furthermore, some OCR tools split compound words or multi-word strings across multiple bounding boxes. A name like "John Smith" may appear as two separate bounding boxes. Drawing one rectangle over both words in the image catches both bounding boxes if the rectangle fully overlaps the name region. Visual inspection of the final exported image remains the definitive check before sharing any redacted document.
Preparing physical documents for scanning before redaction
Document preparation before scanning directly affects the OCR accuracy you get from the extracted text. Flatten any folded or creased pages and remove staples and paper clips before placing documents in the feeder or on the platen glass. Wrinkled areas create shadow gradients that Tesseract may interpret as text artifacts, adding false tokens near creases and making identifier searches less reliable.
Scan settings for high-accuracy OCR output
Scan in Grayscale or Color at 300 DPI minimum for standard body text at 10pt or larger. Documents with handwriting or very small printed fonts below 9pt benefit from 400 DPI, which gives Tesseract better bounding box precision on individual characters.3 Save or export as JPEG at maximum quality or as PNG to avoid compression artifacts on character edges.4 If your scanner exports to PDF and you need a single page image for the OCR Redactor, rasterize the page with ImageMagick at 300 DPI before dragging the output image onto the tool's upload zone.5
Post-export audit of the redacted text file for remaining identifiers
The OCR Redactor's Download Text export produces a plain text file containing the OCR transcript of the document, with redacted tokens replaced by block characters. This file is separate from the exported image and provides a searchable audit record for verifying that every target identifier is covered before the document leaves your control.
Using the text export for identifier verification
Open the downloaded text file in any text editor and use the Find function to search for each target identifier: full names, reference numbers, date patterns, and any other sensitive strings you redacted from the image. If any search returns a match, the corresponding rectangle in the image does not fully cover that token's bounding box. Return to the OCR Redactor, expand or add rectangles over the affected region, and export again. This verification step adds two to three minutes per document and produces a concrete record that each identifier was absent from the final exported PNG.
Make the search step part of your export checklist rather than an afterthought. CapyToolkit's OCR Redactor replaces redacted tokens with block characters in the text file, so a clean Find result across all target strings is the proof that the image rectangles aligned correctly. Saving that text file alongside the redacted PNG gives you a plain-text record you can recheck later if the document is ever challenged or re-shared, which is why teams block a scanned form before digital filing and keep the audit trail.
Use this tool when you need to redact sensitive fields from a physical paper document before digital distribution, when a document exists only as a scanned image with no source digital file, or when you need a text-layer-free export of a partially redacted scan.
Redacting a scanned paper application form before filing
Scan the form at 300 DPI. Drop the page image into the OCR Redactor. Draw rectangles over fields not required by the filing (such as SSN fields on a form where only the name and date fields are needed). Export the PNG.
Processing a scanned contract for redacted archive copy
Scan each contract page. Redact pricing and party identity fields not needed in the archive. Export each page PNG and combine into a redacted archive PDF. Retain the original scans separately for the fully confidential copy.
- 1.
Tesseract OCR, "Improving the quality of the output," tesseract-ocr.github.io, accessed June 2026. https://tesseract-ocr.github.io/tessdoc/ImproveQuality.html
- 2.
ImageMagick, "Command-line Processing," imagemagick.org, accessed June 2026. https://imagemagick.org/command-line-processing/
- 3.
Tesseract OCR, "FAQ (tess3)," tesseract-ocr.github.io, accessed June 2026. https://tesseract-ocr.github.io/tessdoc/tess3/FAQ-Old.html
- 4.
Tesseract OCR, "png vs jpg recognition results are different," github.com, 2019. https://github.com/tesseract-ocr/tesseract/issues/1895
- 5.
ImageMagick, "Command-Line Options: -density," imagemagick.org, accessed June 2026. https://legacy.imagemagick.org/script/command-line-options.php/
300 DPI is the standard minimum. Higher resolutions (400 or 600 DPI) improve accuracy on small fonts and dense tables but produce larger files. For standard 12-point printed text, 300 DPI is sufficient. Go higher only when the source document has very small text or faint ink.
Most operating systems can open a PDF and export a page as JPEG or PNG using a screenshot or built-in PDF viewer. On macOS, open the PDF in Preview, select a page, and export it as JPEG from File > Export. On Windows, print the PDF page to an image using a screenshot or the Microsoft Print to PDF workaround.
Check the text panel after drawing the rectangle. If the word you redacted now shows block characters in the panel, the bounding box overlap was detected. If it still shows the original word, expand the rectangle to ensure full bounding box coverage. The text panel provides real-time feedback for each rectangle you draw.
Yes. Mobile phone document scanning apps produce adequate quality for OCR when used with good lighting and minimal perspective distortion. CapyToolkit accepts images from any source, so a phone scan works well for single-page documents and one-off redaction needs. Dedicated ADF scanners produce more consistent results for batch processing.
Tesseract has limited automatic deskew capability. Scans that are significantly rotated (more than a few degrees) may produce degraded OCR output and misaligned bounding boxes. Straighten the scan before dropping it into the tool using any image editor. Most scanner software includes auto-deskew as a processing option.
Professional document processing and confidentiality
Many professions handle documents that contain sensitive information alongside the text they need to extract. Legal teams, journalists, and HR departments all face the same tension: they need the content in a usable form, but they also need to remove anything that should not leave the organisation. Running OCR and redaction locally keeps that entire workflow under your control.
Workflows that combine extraction and redaction
Several professions routinely process documents that combine the need for text extraction with strict confidentiality requirements. Legal teams reviewing discovery materials need to extract text from scanned files while redacting privileged information before sharing with opposing counsel. Journalists working with leaked documents use redaction to protect sources before publication. HR teams processing paper forms need to extract structured data while removing personally identifiable information before routing it to downstream systems. In each case, sending documents to a cloud OCR service creates an unnecessary copy outside the organisation's control.
Compliance benefits of session-scoped processing
Medical records, financial statements, and government documents are often subject to legal restrictions on disclosure. Because CapyToolkit's OCR runs entirely in your browser with no server communication, you can process these documents without triggering the data handling obligations that would apply to cloud-based alternatives. The session-scoped processing means no residual copy exists after you close the tab, which simplifies compliance documentation for environments with strict data residency or data minimisation requirements.
Redacting personal data from scanned documents
The OCR Redactor does not decide which words are personal data; you do, based on the document and the rules that apply to it. That makes a clear list of identifiers the most useful thing to have before you start drawing. The categories that turn up on scanned forms, the GDPR and CCPA angle, and the combinations of harmless fields that still identify a person follow below.
PII in document images requires both visual and text-layer removal. Drawing a black box over a name in a PDF leaves the name in the underlying text structure, recoverable by any PDF parser. The OCR Redactor exports flat raster images with no text layer, removing the name from both the visual output and the exported text file in a single step.
Personally identifiable information spans a wide range of data types across different regulatory frameworks. GDPR defines personal data broadly as any information relating to an identified or identifiable natural person.1 CCPA covers consumers' names, addresses, email addresses, IP addresses, biometric data, and purchasing history.2 For document image redaction, the practical scope is any field whose content could directly or indirectly identify a living individual.
PII categories commonly found in scanned documents
Scanned administrative documents contain the densest concentration of PII. Employment forms carry full name, SSN, address, date of birth, and compensation information on a single page. Insurance forms add health plan IDs, policy numbers, and claim history. Tax documents include SSNs, EINs, complete income disclosure, and dependent identification. Each of these document types follows a predictable layout that places identifiers in consistent positions, which makes it practical to build a per-document-type redaction checklist that covers every field without needing to discover identifiers ad hoc on each scan.
Contracts, academic records, and regulatory document PII
Contracts between individuals contain names, addresses, and signature blocks that identify the parties and their obligations. Academic records include student IDs, grades, and institutional IDs that link a specific person to their educational history. Consequently, any document produced in an administrative or regulatory context is likely to contain multiple PII categories that require assessment and selective redaction before sharing or archiving. Regulatory filings such as SEC disclosures and public company reports embed executive names, compensation figures, and contact information in structured sections that must be evaluated against the applicable disclosure rules before the filing is made public. The practical implication is that even documents that appear to contain only business data often embed personal identifiers in executive signature blocks, contact sections, and filer identification fields that must be assessed against the relevant disclosure framework.
GDPR and CCPA considerations for document redaction
Under GDPR Article 4, personal data includes any information by which a natural person can be directly or indirectly identified. Indirect identification through a combination of fields, for instance job title plus location plus age, satisfies the definition even without a name.3 CCPA covers broadly similar ground for California residents. Both frameworks require organizations to implement appropriate technical safeguards when processing personal data. Building on this, document redaction satisfies the "data minimization" principle in both GDPR and CCPA: sharing only the data elements necessary for the disclosed purpose and covering the rest constitutes a recognized technical safeguard for limiting exposure.3
Workflow for PII redaction in document processing pipelines
Establish a PII taxonomy for your document type before processing. List every field that constitutes PII in the context of your regulatory framework and your organization's privacy policy. For each document image you process, draw rectangles over every field on the taxonomy list. Review the text panel to confirm covered fields appear as block characters. Export the PNG, which leaves no recoverable representation of the covered identifiers in the file at all4. For high-volume processing, identify which document page layouts contain PII in predictable positions (such as the header of every page of a standard form) and develop a consistent rectangle placement routine for those positions. Yet the export must always be visually inspected before distribution, because layout variations between form versions can shift PII to unexpected positions.
Aggregation risk: when combinations of non-PII fields become identifying
A single field such as employer name, job title, or ZIP code is not PII in isolation. When a document displays employer, title, department, age range, and ZIP code together, those fields can uniquely identify a small number of individuals in a population even without a name or government identifier.5 This is aggregation risk: individual fields that each fall below a PII threshold combine into a profile that effectively identifies a specific person.
Applying aggregation risk analysis to your redaction decisions
Before finalizing your rectangle placement, list all non-name fields still visible in the document. For each combination of two or three of those fields, consider whether that combination would narrow the population to a handful of individuals. Fields that contribute to re-identification should be treated as PII for disclosure purposes even if no regulatory definition enumerates them. In practice, this means reviewing the exported image with fresh eyes after completing all required-field redactions and asking whether any visible combination of remaining fields would allow a determined recipient to identify the subject without additional information.
Building a PII redaction checklist specific to each document type
Different document types carry PII in different structural positions. A standard employment contract places the employee name in the header and the Social Security number in the compensation schedule. A medical intake form distributes PII across the patient demographics section, the insurance section, and the signature block at the bottom. A generic approach of redacting all names and numbers misses fields specific to each document's structure.
Structuring a per-document-type checklist
Create a short checklist for each document type you process regularly. For each type, list the section name and field label where PII typically appears: for an employment contract, note the header block, the signatory block, and the tax form line; for a medical intake form, note the demographics row, the insurance identifier, and the emergency contact fields. Before beginning each redaction session, display the checklist for the current document type and check off each position as you place rectangles. This method catches positional PII that visual inspection alone tends to overlook when working through multiple pages under time pressure.
Reuse the same checklist whenever a new version of the form appears, because most redesigns keep the PII fields in familiar positions. CapyToolkit's OCR Redactor redacts exactly the regions you mark, so the checklist is what keeps positional coverage consistent across batches rather than relying on memory. If a new form version moves a field to a different row, update that one entry and the rest of the list carries over unchanged, which is faster than rebuilding the review from scratch each time, so wipe PII fields before cross-border transfer using a checklist you trust.
Use this tool when preparing document images for sharing with parties who should not receive full personal information, when creating anonymized document sets for testing or research, or when complying with data minimization requirements before cross-border data transfers.
Anonymizing employment application forms for recruitment analysis
Redact name, address, SSN, and date of birth fields. Leave job history, skills, and education visible. Export the PNG set. The anonymized forms can be shared with analytical teams without personal identification.
Preparing insurance claim forms for compliance audit
Redact policyholder name, policy number, and medical information not required for the audit scope. Leave claim amounts and processing dates visible. Export each page PNG for the audit binder.
- 1.
European Union, "Regulation (EU) 2016/679, Article 4(1)," eur-lex.europa.eu, 2016. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32016R0679
- 2.
California Legislature, "California Civil Code § 1798.140(v)," leginfo.legislature.ca.gov, 2026. https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=CIV§ionNum=1798.140
- 3.
ISO, "Information technology — Security techniques — Specification for digital redaction," ISO/IEC 27038:2014, iso.org, 2014. https://www.iso.org/standard/44382.html
- 4.
UK Information Commissioner's Office, "Can we identify an individual indirectly from the information we have?," ico.org.uk, accessed June 2026. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/personal-information-what-is-it/what-is-personal-data/can-we-identify-an-individual-indirectly/
- 5.
NIST, "Guide to Protecting the Confidentiality of PII," SP 800-122, nist.gov, 2010. https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-122.pdf
No. The OCR Redactor extracts text from the image but does not automatically classify which text constitutes PII. You identify the fields based on your knowledge of the document type and applicable regulations, then draw rectangles over them. Automated PII detection would require a separate classification layer not included in this tool.
Yes, with caveats. A data subject access request requires providing the subject with their own data, including PII about themselves. However, documents containing information about multiple individuals require redacting other individuals' PII before disclosure to the requesting subject. This tool enables that selective redaction.
Redaction of direct identifiers can achieve anonymization if the remaining data cannot be used to re-identify the individual, directly or indirectly. GDPR's anonymization standard is high: truly anonymized data falls outside GDPR scope, while pseudonymized data remains covered. Whether your redacted document qualifies as anonymized depends on the specific combination of remaining fields and the context.
Tesseract may not accurately extract handwritten text, but the visual redaction layer covers the image region regardless of OCR accuracy. Draw rectangles over handwritten PII fields based on their visual position on the form. The visual redaction applies to the image pixels directly, independent of what OCR detected in that region.
CapyToolkit's OCR Redactor processes data locally in your browser with no transmission to external servers, supporting the data minimization and security principles under GDPR. Whether your overall workflow is GDPR-compliant depends on your organizational controls, data retention policies, and the processing purpose, which are outside the scope of any individual tool.
Best-Result Scan Checklist
- 300+ DPI scan Tesseract's own documentation recommends at least 300 DPI. Anything lower increases recognition errors.
- Strong contrast, no skew Dark text on a light background, deskewed and tightly cropped, segments more reliably than a noisy, tilted photo.
- Printed text, not handwriting The bundled English model was trained on printed fonts. Handwriting accuracy varies widely and has no dedicated fix.
- Under 20MB file size JPEG, PNG, and WebP are supported up to 20MB per file.
Scan your own document above and check it against these four conditions before you rely on the extracted text.
- 1.
Naptha, "Tesseract.js API Documentation," github.com, accessed June 2026. https://github.com/naptha/tesseract.js/blob/master/docs/api.md
- 2.
MDN contributors, "WebAssembly," developer.mozilla.org, May 2026. https://developer.mozilla.org/en-US/docs/WebAssembly
- 3.
Tesseract OCR contributors, "Traineddata Files for Version 4.00 +," tesseract-ocr.github.io, accessed September 2026. https://tesseract-ocr.github.io/tessdoc/Data-Files.html
- 4.
Tesseract OCR contributors, "Command Line Usage," tesseract-ocr.github.io, accessed June 2026. https://tesseract-ocr.github.io/tessdoc/Command-Line-Usage.html#tsv-output
- 5.
MDN contributors, "Web Workers API," developer.mozilla.org, April 2025. https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API
- 6.
Tesseract OCR contributors, "Improving the quality of the output," tesseract-ocr.github.io, accessed June 2026. https://tesseract-ocr.github.io/tessdoc/ImproveQuality.html
- 7.
Tesseract OCR contributors, "FAQ," github.com, accessed June 2026. https://github.com/tesseract-ocr/tessdoc/blob/main/FAQ.md