Local OCR & document scanning

A scanner or phone camera captures an image of the page. The PDF wraps that image, but underneath there are no actual characters — just pixels shaped like letters. Your eyes read them fine; software sees a picture. That's the difference between a scanned PDF and a searchable one, and it trips up everyone digitizing a personal library, archiving paperwork, or scanning a chapter of notes they now can't search.

The fix is OCR — optical character recognition. Good OCR doesn't replace the page you see; it adds an invisible layer of recognized text behind the image. The result looks identical to your scan, but now it's searchable, selectable, and copyable while still showing the original pages. That hidden text layer is the whole point of a "searchable PDF."

It matters because a scan you can't search is only half a document — you can't find a phrase, quote a sentence, or pull a figure. And the failure is quiet: OCR that runs but mangles a ligature or drops a hyphenated line break produces a file that looks fine until a search for a phrase you know is in there returns nothing. So two things decide whether OCR was worth doing: coverage (does it add a real text layer to every page) and accuracy (does that layer actually match the page). If you only need the words and not the layout, a plain-text export is smaller and easier to grep — but you lose the visual fidelity a searchable PDF keeps.

This is the sharpest version of the problem, because OCR is most useful precisely on documents you'd never want to leak: a contract you're making searchable, a screenshot of a statement you're pulling a number from, a photographed handwritten note, a dense table or LaTeX equation trapped in a PDF with no text layer. When people go looking, they find three disappointing options. Free web OCR sites require uploading the document — the worst possible thing to do with personal letters, legal paperwork, medical records, or financial files. Heavyweight office suites bury OCR five menus deep, behind the expensive tier, in software far larger than the task needs. Raw OCR engines are powerful but command-line and fiddly to install — not something a non-technical person wants to wrestle with just to search a scanned book.

The frustration in the recognition crowd usually isn't accuracy — modern offline models handle screenshots, mixed layouts, math, and even messy handwriting respectably. It's that the convenient tools want the source image on their servers. When that image is a confidential document, the trade is unacceptable, so people either retype by hand or hold their nose and upload. And the privacy cost is asymmetric: cloud tools strip sensitive data on output but not on input, so for the duration of the job the original — card numbers, addresses, signatures intact — sits on someone else's storage, sometimes retained indefinitely for "model improvement." Running OCR locally removes the dilemma entirely: recognition happens on your machine, against the original file, and the text lands back on disk with no round trip.

Here's what most guides skip: OCR engines, paid or free, behave roughly the same on the same input. What separates a 99%-accurate run from a 60%-accurate one isn't the engine — it's the prep that happens before the engine sees the image. A phone photo of a receipt held at an angle reads at about 88%; the same photo deskewed to vertical reads at 99%. Four steps do most of the work:

1. Deskew and orient — detect the dominant text-line angle and rotate to compensate. Once.
2. Crop to the document — backgrounds confuse OCR; a receipt on a wood counter wastes the engine's attention on grain. Crop tight to the paper with a small margin.
3. Normalize contrast and resolution — stretch contrast so blacks are black and whites are white; downsample anything over 300 DPI to 300 (more is noise), upsample very low-DPI scans with sharpening.
4. Convert to grayscale — color doesn't help receipt OCR, cuts file size roughly 3x, and unifies the engine's input so every image looks like every other.

Two corner cases recur. HEIC from an iPhone: most OCR engines can't read it natively, so converting HEIC to JPEG first fixes about a third of "OCR can't read my receipt" complaints. Multi-page PDFs: rasterize to per-page images so each page gets its own crop and contrast tuning — which matters because PDFs often mix scanned and digital pages in one document. Run the four steps in order, then hand the clean result to whatever OCR you trust; the output goes from "kind of works" to "actually works."

Batch OCR is the dividing line in PDF software. A toy tool can process one small document; a serious workflow has to handle many large files, preserve readability, and not quietly skip pages. This is exactly where free web tools stop feeling free: someone with sixteen or seventeen already-compressed 250 MB PDFs doesn't need a clever landing page, they need throughput, clear failures, and OCR that doesn't garble the output — and the free tier meters per page or caps file size right when the job gets real. It isn't only the free web tools that stall here, either — people report that Acrobat's newer OCR was pushed into a hard-to-find, browser-based workflow that still chokes on large documents, which is part of what sends them to a local batch pass in the first place.

There's a cost angle too. Routing a thousand dense, multi-column pages through a hosted vision model gets expensive fast, and the bill scales with the corpus, not with how much you use the output. The smarter shape is to run the bulk pass locally — a fixed cost in your time and CPU instead of a per-page meter — then reserve any paid AI model for the short tail of pages that genuinely defeat a local engine. The constraint stops scaling with the corpus.

Batch also raises the stakes on privacy: you're handing over not one file but a whole folder of context — contracts, archives, client material. A local run lets you queue the files, inspect failures, retry with different settings, and keep the originals close, without every attempt being a fresh upload. And OCR rarely stands alone in a batch — it sits next to compression, splitting, and conversion, so having those adjacent operations in one place is what lets you finish a deadline batch without stitching together a temporary toolchain.

This job looks like the scanned-PDF problem but its binding constraint is accuracy, not privacy, and the failure mode is subtle. Bad OCR doesn't announce itself — it produces a file that looks fine until a search for a phrase you know is in there returns nothing, because the recognizer quietly mangled a ligature or dropped a hyphenated line break. So the first lever isn't a post-processing trick; it's faithful capture. Consistent lighting, a flat page, and a resolution high enough that small type survives are worth more than any cleanup afterward.

Then choose the output for how you'll use it. A searchable PDF keeps the page image you can trust your eyes on and layers recognized text underneath for search and copy — best when layout matters or you want to keep reading the original. A plain TXT export is smaller and easier to grep, at the cost of losing layout — best when you only need the words. Either way the job is whole-document: a 300-page book scanned and OCR'd in one pass, not one page at a time.

The quiet advantage of doing this locally is patience without penalty. A cloud service might be marginally faster on a single book, but you're handing over the full text of something you scanned and inheriting whatever its recognizer decides. Locally, you can re-run a chapter that came out wrong without re-uploading anything — which, on a long book where a few chapters always come out worse than the rest, is the difference between a clean result and giving up halfway.

Two versions of this keep showing up. One is the AI-context version: raw PDFs burn tokens, and people increasingly want a PDF turned into clean text or Markdown to use as model context — specs, docs, references pasted into a chat. The other is more basic: a 63 MB, 112-page handwritten-notes PDF that someone wants to extract clean text from before sending it to a model, or numbered callouts pulled out of an assembly diagram, or text found inside a folder of images. In every case the missing step is the same — the document behaves like images, so search and copy/paste fail, and you need a reliable local pass that turns it into text.

The right mental model is to separate the deterministic step from the AI step. OCR and text extraction are the deterministic first stage: get the words out, accurately, on your own machine. Formatting that text into Markdown, summarizing it, or reasoning over it is a downstream stage you can hand to whatever model you like — but only after you have clean text, and ideally without shipping the original file anywhere. Doing the extraction locally matters most here because these are exactly the documents you'd hesitate to upload: handwritten notes, internal specs, scanned archives. Extract on-device, review the text, then decide what (if anything) goes to a model. A tool that does clean local extraction gives the AI step the input it needs without making the privacy decision for you.

The job sounds simple until it has to be repeated. You receive one combined PDF containing dozens of invoices; splitting every page into a separate file isn't enough, because a tool that outputs page-1.pdf through page-80.pdf technically split the document and still failed the workflow — now you have a manual renaming job. What you actually want is invoices separated and named by vendor, date, and invoice number, previewed before you commit, and done without uploading financial documents to an unknown service.

There's a broader prep pattern behind this for anyone doing bookkeeping. The expensive part of receipt and invoice work isn't the OCR the accounting software runs — it's everything before it: rotate, crop, deskew, compress, split per page, and rename so the software's OCR can pull line items without choking on a 4 MB phone photo. A working shape is a watched inbox folder: drop raw files in, a monitor runs the prep-and-split preset automatically, and clean, structured output lands in a dated folder — "drop the file, walk away." Some name fields (the amount, the exact vendor) can't be filled until after OCR; use a placeholder and patch the name once the result comes back. The point is that every file gets a structured name from the start instead of arriving as IMG_4732.HEIC and becoming a future archaeology problem. Splitting at the prep stage also lets each page get its own crop and contrast tuning, which matters because multi-page PDFs often mix scanned and digital pages.

Plain OCR solves half of this and quietly fails the other half. Run recognition on a scanned invoice, bank statement, or price list and you get the words back — but a table isn't just words, it's words arranged in a grid, and most OCR output flattens that grid into a single stream. The numbers come out in reading order, the column boundaries vanish, and what should have been neat rows and columns lands in your document as one long paragraph you now have to re-tabulate by hand. That's why "scanned tables to Excel" is a genuinely different job from "make this PDF searchable": the searchable version keeps the picture of the table; the spreadsheet version needs its structure.

Two things make it hard. First, the ruling lines in a scan are often faint or broken, so the software has to infer where one cell ends and the next begins from spacing alone — and a receipt photographed at a slight angle throws that spacing off immediately. Second, real pages mix tables and prose, so a naive extractor grabs the surrounding sentences too. The reliable path is the same order that fixes ordinary OCR: prep the image first — deskew, crop tight to the table, raise contrast so the digits and rules are crisp — then recognize. Clean input is what lets column detection work at all.

And because the documents that arrive as scanned tables are almost always financial — invoices, statements, expense reports, ledgers — the one move you don't want to make is uploading them to a web converter just to get a spreadsheet back. Pull the values out on your own machine, then reshape them into columns where the sensitive data already lives.

The complaint is consistent enough to be its own category: the phone scanner apps people reach for are stuffed with ads, gate basic features behind an account, and quietly upload the very things you're scanning — receipts, IDs, medical forms, signed paperwork — to a server you know nothing about. All you wanted was the boring part: point the camera at a page, get straight edges, capture several pages into one file, and have the text be searchable afterward. Instead the "free" app turns a private document into someone else's data.

Splitting the job in two removes the cloud entirely. Capture is just photos — any phone camera takes them, no special app required; hold the page flat, fill the frame, keep the light even. Everything after that is ordinary desktop file work you can do locally: straighten and crop each shot to the paper, raise contrast so faint print survives, combine the pages in order into a single PDF, and OCR the result so it's searchable and copyable instead of a stack of images. Done this way the document never leaves your machine — no account, no watermark, and no "share when ready" button that actually means "upload now."

The multi-page part matters more than it sounds. A real scan is rarely one page, and a tool that can only handle a single image at a time falls apart the moment you have a three-page contract or a month of receipts. Batch the prep so a whole stack cleans up in one pass, then OCR once at the end — the same edge-detect / crop / searchable-PDF workflow the ad-heavy scanner apps sell, minus the ads, the login, and the upload.

It happens more than people plan for: someone builds a whole document workflow on a hosted "PDF OCR" service, then one morning the logins stop being accepted and the pipeline is just gone — files stranded, no export, no warning. A hosted OCR is a dependency you don't control. The price can change, the login can break, the company can quietly fold, and in the meantime your documents have been sitting on somebody else's disk. For a one-off that might be an acceptable trade; for anything recurring or sensitive it's a bad foundation.

The reassuring part is that OCR stopped being a hard, server-only problem years ago. Turning an image of text into selectable text runs perfectly well on an ordinary laptop now, so paying a subscription and uploading a contract to get it back as text is mostly buying convenience you can own outright. The job usually has three shapes, and it's worth knowing which one you actually have: sometimes the PDF already contains a text layer and you just need to pull it out; sometimes it's a pure scan or photo with no text at all and you need real OCR; and sometimes you want the result editable rather than just searchable. Those are different operations, and reaching for OCR when the text was already there wastes time and garbles good text.

The durable setup is to do all three locally: extract an existing text layer when one exists, run OCR only when it doesn't, and export to a format you own — a searchable PDF, plain text, or an editable document — so the result never depends on a service still being in business next month.

"OCR" quietly covers two very different jobs, and conflating them is why people end up disappointed. Printed and typed text — books, invoices, forms, scanned documents — is effectively a solved problem you can do locally: a good engine reads clean printed scans at high accuracy with nothing uploaded. Handwriting is a different problem entirely.

General-purpose OCR is trained on printed glyphs. Cursive, personal shorthand, and mixed layouts degrade it quickly, and no local tool is going to match a human transcriber on a full handwritten notebook. Set expectations accordingly: neat, consistent block printing on a clean, high-contrast scan can come through usable; cursive and messy pages will need correction, and for some notebooks manual transcription is genuinely faster than fixing garbled output.

What you can do locally and reliably is the printed side: batch-OCR large scanned PDFs into searchable, selectable text or an editable document, offline, on your own machine. That also solves the common AI-adjacent goal — feeding a scan to a model. Don't hand an AI a raw scanned PDF; it burns tokens and confuses the model. Extract clean text first, then feed that. For handwriting, improve your odds with high-resolution captures, good lighting and contrast, and one column at a time — but treat whatever comes out as a draft to review, not a finished transcript.

Camera-scanning a book is a batch geometry problem, and doing it in the right order is most of the work.

• Sort before anything else. Capture time is your ordering key — filenames from a camera are reliable within a session but not across cards. Lock the order first; every later step depends on it.
• Fix perspective per page, not globally. Even on a tripod, page curvature and the spine mean each spread sits slightly differently. Corner detection per page beats one crop applied to all 400.
• Crop consistently after straightening, not before. Cropping first bakes in the skew.
• Review on a contact sheet. Forty thumbnails at a time will surface the misfires — a hand in frame, a missed page, a double capture — far faster than paging through one by one.
• Enhance for legibility, not beauty. Modest contrast and a light de-yellowing help both reading and OCR. Aggressive thresholding to pure black-and-white destroys thin strokes and makes OCR worse.
• Assemble, then OCR. Build the PDF in order first, then run OCR over the finished document. It keeps page numbering honest and gives you one searchable file.
• Keep the originals. Every step above is destructive; the untouched JPEGs are your only route back if the crop was wrong.

Expect the review step to catch a handful of pages you'll re-shoot. That's normal at 400 pages, and cheaper than discovering it after binding.

At five thousand pages, the question stops being "can this tool OCR my file" and becomes "what happens when it fails at page 3,200". Every approach that treats the document as one atomic operation will eventually lose hours of work, and the cloud services that used to absorb this either changed, throttled, or disappeared.

Structure the job so a failure costs you one chunk, not the run:

• Chunk by page range. Split into blocks of a few hundred pages, OCR each, merge at the end. A crash costs one block. This single change is the difference between an afternoon and a week.
• Checkpoint completed chunks to disk. Finished blocks should be on disk as finished files, so restarting picks up where it stopped rather than at page one.
• Let per-page failures be per-page. One corrupt or bizarre page shouldn't abort the block. Log it, skip it, deal with the list at the end.
• Detect what actually needs OCR. Mixed documents often have thousands of pages that already contain a text layer. Skipping those can halve the work.
• Estimate before you start. Pages, expected minutes, and free disk space. OCR output plus intermediates can exceed the source substantially, and running out of disk at page 4,000 is a self-inflicted restart.
• Do it locally. At this size, upload time alone is significant, the per-file caps on hosted services are below your file, and these are usually documents you'd rather not hand over anyway.

OCR gives you a text layer for searching. It does not give you an editable document. To change a word in place on a scan, something has to erase the pixels of the old word and synthesise new pixels that match — which means recovering the font family, weight, size, letter spacing, baseline position, ink colour, and the paper texture behind it. OCR recovers characters and a bounding box. Everything else is inference.

And scans are never clean. There's a fraction of a degree of rotation, JPEG noise, a scanner's colour cast, bleed-through from the reverse side. A replacement word rendered in a close-enough font on a freshly-whitened patch is visible at a glance. On a document that matters — a contract, an invoice, a certificate — that's worse than not editing at all, because it doesn't read as a correction, it reads as tampering.

So the honest routes, in descending order of fidelity:

• Annotate over it. Strike through, add a correction box, add a dated note. Nothing is hidden and nothing is forged. For most "this is wrong" cases this is the correct answer, not the fallback.
• Rebuild the page. If you need genuinely editable text, convert the scan into a word-processor document, fix it there, re-export. You trade the original's visual fidelity for text that's actually text.
• Patch in place. Reasonable only when the type is a common font, the line is horizontal and clean, and the change is small. Keep the untouched original alongside it.

Three things a tool owes you if it offers in-place editing at all: confidence (how sure is the recognition for the region I'm about to edit), preservation (never overwrite the original scan), and rollback that's one click. If it can't tell you how sure it is, treat any in-place edit as a cosmetic overlay rather than a corrected document.

Worth naming the other case: if you want to edit the scan because the underlying fact is wrong, editing the image is the wrong instrument entirely. A scan is a record of what was on the paper.

Once you know each page counts as an image, the question stops being "how do I upload this document" and becomes "what is the smallest artifact that still answers my question." That reframing is worth more than any workaround, because it's also the cheaper, faster, and more private option — the parts of a document that never leave your disk can't be misread, retained, or billed.

Decide what the model actually needs to see:

• Only the words → extract the text and send that. A 50-page report is a few tens of kilobytes of text and zero images. This covers most summarising, analysis, and question-answering.
• Only the words, but it's a scan → OCR once, locally, keep the text, send the text. Doing it once on your machine beats re-uploading the same scan into every new conversation and paying the image cost each time.
• Layout carries meaning — a form, a chart, a table whose structure is the point → send just those pages. Split out 12–14 rather than attaching the whole document.
• The images matter and they're huge → downsample first. A 4000px scan of a page is not more legible to a model than a 1500px one; it just costs more of your allowance.

The general shape: do the deterministic reduction on your machine, then hand over the smallest thing that still contains the answer.

One caution, because it's the failure people hit after they get good at this: extracting text collapses layout. If your question is positional — which column a figure sits in, whether a checkbox is ticked, how a two-page table continues — text extraction quietly discards the exact thing you're asking about, and the answer will be confident and wrong. When the geometry is the question, send the page.

This is a pipeline with four independent stages, and most people over-invest in the one that matters least — raw scan resolution — and skip the one that decides the outcome.

Capture. 600 DPI is the right archival default for pages you may never be able to rescan, and fragile single sheets are exactly that case. If the per-page time is the bottleneck, the answer isn't a lower setting; it's separating capture from processing so you handle each fragile sheet exactly once. Scan everything first, tune the recognition later, on copies.

Cleanup. This is where handwriting OCR is won or lost. Pencil is low-contrast graphite on paper that has yellowed for four decades, and the recognizer sees a muddy mid-grey field with letter-shaped noise in it. Convert to greyscale, push contrast, lift brightness, then sharpen — a cleaned 300 DPI page routinely beats an untouched 600 DPI one. Tune the cleanup on a dozen representative pages (worst-faded, cleanest, one with pencil smudging) and then apply that recipe to the batch.

Recognition. Handwriting recognition is probabilistic, and 40-year-old block lettering will produce confidently wrong words. So stop asking how to make it perfect and decide what to do with text you can't fully trust.

Assembly — the part people skip. Build the output as page image plus a text layer, never text alone. The scan stays the document of record; OCR is only the index that helps you find the page. Then a misread costs you a search miss instead of a lost record, and a human reading the page can always see what it really says. Spot-check every twentieth page against its image to get a rough error rate — that one number tells you whether to hand-correct the batch or accept it as a finding aid.

Handwriting recognition also improves every couple of years. Because the images are preserved and the text layer is disposable, you can re-run recognition on the same archive later and keep the better result. That's only true if you kept the scans at full quality.

The gap you hit is real and slightly odd: single-image OCR is everywhere and bulk OCR with one output per input is not. That specific requirement rules out most of what you'll find, because tools that batch tend to concatenate.

What a workable local pipeline needs:

• One output per input, named from the source file. If you have to re-associate text with images afterwards, the batch saved you nothing.
• Streaming rather than loading everything. This is the memory problem people run into: an implementation holding every decoded image and every result in memory dies partway through a large folder. Processing page by page and writing as you go keeps usage flat no matter how big the folder is.
• Resumable jobs. A run over hundreds of files will be interrupted. Skipping already-processed files turns a failure into a restart instead of a redo.
• Explicit language selection. Mixed-language folders are where accuracy quietly drops. Engines do markedly better when told which languages to expect than when guessing — and worse when handed a long list they don't need.
• A confidence signal you can sort by. The whole value of batching is reviewing the worst five percent instead of all of it.

On the question of combining images into a PDF first: only do that if you want one searchable document at the end. If you want per-file text, combining adds a step and then forces you to split the result back apart. Go image to text directly.

And the reason to keep it local isn't only privacy. A folder of hundreds of files is exactly the workload that runs into rate limits, per-page pricing, and upload caps on hosted services — which is why the free tools you found were all one-at-a-time.

It's both, and separating them tells you which knob to turn.

The script problem is real. Devanagari — and Indic scripts generally — use conjunct consonants and vowel marks that combine into a single visual cluster, plus a connecting headline running across the top of each word. Engines built around discrete Latin glyphs sitting on a baseline have to be trained specifically for this, and many are trained lightly or not at all. Arabic has the same issue for different reasons (cursive joining, contextual letter forms), as does CJK. So "OCR is bad on Hindi" is usually "this engine's Hindi model is bad," not a ceiling on what's possible.

What actually moves accuracy, roughly in order of effect:

• Use an engine with a real model for that script, and declare the language explicitly. Auto-detection on non-Latin text is where a surprising amount of the loss happens.
• Fix the input first. Around 300 DPI, deskewed, high contrast, no JPEG artifacts. This is marginal on clean English text and decisive on scripts with fine diacritics, where a vowel mark and a speck of scanner noise are the same number of pixels.
• Segment by block. Mixed-script documents — Hindi body text with English technical terms — do better processed as regions with the correct language each than as one page with two languages declared at once.

On translation, keep it as a separate step from recognition. Bundled together, an OCR error becomes a fluent and confident mistranslation with no way to see where it went wrong. Get the source text out, check it against the page, then translate — and expect to proofread, because a document worth translating is usually one where a wrong number matters.

Set expectations accordingly: word-perfect output on difficult scanned Devanagari isn't available from any tool today. A good pipeline gets you a draft that's faster to correct than to retype.