# Batch-Converting Scanned PDFs into a Searchable Archive: Choose Your Path by Need, with Real Costs from 600+ Pages

> Have a large batch of image-only scanned PDFs you want to make searchable and properly filed? This article breaks the problem into four paths: no-code desktop software, free OCRmyPDF, cloud OCR, and the AI page-by-page transcription plus OCR approach I used this time. Includes real costs from 600+ pages (additional usage fees around US$7: AI transcription ~US$9.6 per 1,000 pages, cloud OCR US$1.50 per 1,000 pages), measured quality gaps between free and cloud OCR, and data-policy questions to answer before uploading anything.

- Author: Paul Kuo（郭曜郎）
- Date: 2026-10-24
- Pillar: Creation & Enterprise
- Tags: Scanned Document Digitization, OCR, Searchable PDF, OCRmyPDF, Azure AI Document Intelligence, Claude Batch API, Field Notes
- Canonical: https://paulkuo.tw/en/articles/scan-to-searchable-archive/
- Language: English
- Translation: AI-translated from the zh-Hant (Traditional Chinese) original
- Original (zh-Hant): https://paulkuo.tw/articles/scan-to-searchable-archive.md
- Site index for LLMs: https://paulkuo.tw/llms.txt

---

> **TL;DR:** To make a large batch of scanned PDFs searchable, one OCR pass is enough. OCR is the technology that reads text from images and makes it findable by a computer. If you prefer no coding, use desktop PDF software. For a free, files-stay-local option, use OCRmyPDF. For high page counts where cloud upload is acceptable, use cloud OCR at roughly US$1.50 per 1,000 pages. If you also need to know what each page says and want to classify and catalog everything, add AI page-by-page transcription and cross-check the two outputs. My 600+ page run on that last path added about US$7 in usage fees, not counting my existing AI subscriptions or time. The original scans were kept separately and never touched.

Just after 6 p.m. I downloaded a 90 MB PDF: 600+ pages of English paper documents, every page a bare image. Searching for any word returned zero results. The file came with a page-number index listing which pages belonged to which document.

My initial plan was just to convert the content to text. By around 9 p.m. I had decided to go further and organize everything into a coded archive for colleagues. Just after midnight, the result was 80+ individually searchable PDFs, each paired with a Word text file (convenient for searching and copying, but not authoritative), topped by a master index in Excel and a usage guide.

Processing large batches of scanned PDFs is a common need, so I have organized this experience into a decision guide. It opens with four paths keyed to what you want, each with an approach, costs, and limitations. The actual run appears under Path 4. This article is not a step-by-step tutorial, and the code I wrote is not published.

Claude did most of the work: it wrote the code, assembled the files, and ran the verification. I defined the scope, made the calls, and personally opened the cloud account. The steps involving account credentials I ran myself on my own machine. People who do not code can use the same division of labor: hand this article's decision table, transcription rules, and official documentation links to a coding AI agent (one that can write and execute code on your computer, such as Claude or Codex) and ask it to proceed. Note that whatever the agent reads, including file contents, screen output, and error messages, gets sent to that AI service. Keep sensitive documents out of the agent's hands and run those steps yourself.

## What Result Do You Need? Pick a Path First

Two questions: Do you need only searchability, or do you also need classification and cataloging? Can the files be uploaded to the cloud?

| | What you want | Approach | Coding required | Files go to cloud | Cost | Did I test it |
|---|---|---|---|---|---|---|
| Path 1 | Searchability only | Desktop PDF software's OCR function | No | Usually no; check each app's documentation | Software subscription or license fee | Not tested |
| Path 2 | Searchability only; free; files stay local | OCRmyPDF (backed by Tesseract) | Must open terminal, install tool, type commands | No | Free | Tested Tesseract |
| Path 3 | Searchability only; high page count; cloud upload acceptable | Cloud OCR | Yes, or ask an AI agent to write it | Yes | ~US$1.50 per 1,000 pages | Tested Azure |
| Path 4 | Also need to read each page, classify, catalog | AI page-by-page transcription plus OCR, then code-assembled files | Yes, or ask an AI agent to write it | Yes, two cloud services | ~US$11 per 1,000 pages this run | This is the approach I used |

> **Three questions before uploading:** Does the file contain ID numbers, medical records, or non-public business information? Does company policy or the data owner permit uploading? How long does the service retain data, does it use data for training, and can you request early deletion? If any of these cannot be answered, do not upload yet. Use Path 2, or use desktop software you are certain runs entirely on your own machine. When using an AI agent, remember that file contents, screen captures, and error messages are all sent to that AI service. For sensitive documents, run the commands yourself rather than letting the agent open the files.

Regardless of which path you take: copy the original before doing anything, and run every step on the copy. Then pick your five hardest pages for a trial run: pages with tables, handwriting, sideways orientation, or dense small text. Run the tool, search for a few words, compare against the original image, and confirm the quality is acceptable before processing the full batch.

## Path 1: Searchability Only, No Coding, Use Desktop PDF Software

Open the PDF, run the software's text recognition (OCR) function, save, and you have a searchable PDF.

Using Adobe Acrobat Pro as an example (the free Acrobat Reader does not include this feature): open a copy of the scanned PDF, then go to All tools, Scan & OCR, Recognize Text, In This File, and click Recognize Text. In the settings, if an output type is offered, choose Searchable Image (Exact): this overlays text on the original image without altering it. Editable Text and Images replaces the scanned image with re-flowed text, and Searchable Image resamples the image. When done, use Save As to write a new filename such as "originalname_searchable.pdf"; do not overwrite the original with Save. The menu names above are for the English interface; in a localized interface, look for options related to "Scan" and "Recognize Text." Adobe's help page is titled [Recognize text in scanned documents](https://helpx.adobe.com/acrobat/desktop/create-documents/scan-documents-to-pdfs/recognize-text.html). ABBYY FineReader PDF and similar applications offer the same capability.

I did not run this path myself for this project. The steps above are drawn from Adobe's help page and two university library guides ([step-by-step walkthrough](https://kb.uwstout.edu/155829), [output type explanation](https://guides.lib.ku.edu/ocr/acrobat)). Menu layouts vary by version, and pricing varies by plan and region.

## Path 2: Free, Files Stay Local, Use OCRmyPDF

[OCRmyPDF](https://github.com/ocrmypdf/OCRmyPDF) is a free, open-source tool that adds a text layer to an entire PDF with one command. Files never leave your computer. It requires the terminal, which is the window on your computer where you type commands. On a Mac, find it in Applications under Utilities, or search for "Terminal" with Spotlight.

On a Mac, first install Homebrew by following the instructions at [brew.sh](https://brew.sh/). Homebrew is the package manager used to install tools like this. Then run these two commands in the terminal, one at a time:

```bash
brew install ocrmypdf
ocrmypdf --version
```

The second line prints a version number, confirming the installation succeeded. To recognize languages other than English, also run `brew install tesseract-lang`.

Create a working folder, put a copy of your PDF inside it, then type `cd` followed by a space in the terminal window, drag the folder into the window, and press Enter to navigate to it. Then run:

```bash
ocrmypdf -l eng input.pdf output.pdf
```

Replace `input.pdf` with your actual filename. If the filename contains spaces, wrap it in quotes: `"my scanned file.pdf"`. The result is written to `output.pdf`; the original is not overwritten. For Traditional Chinese, replace `eng` with `chi_tra`; for mixed English and Chinese, use `eng+chi_tra` (codes are listed in the [OCRmyPDF language guide](https://ocrmypdf.readthedocs.io/en/latest/languages.html) and the [Tesseract language code table](https://tesseract-ocr.github.io/tessdoc/Data-Files-in-different-versions.html)). After it finishes, open the new file and search for a few words to confirm the text layer is there.

For pages that are upside-down, sideways, or skewed, you can add `--rotate-pages` (to straighten orientation) and `--deskew` (to correct tilt) after `-l eng`. These options alter the page images in the output file; leave them out if you want to preserve the original appearance exactly. Windows installation instructions are in the [official installation guide](https://ocrmypdf.readthedocs.io/en/latest/installation.html); work through it until `ocrmypdf --version` succeeds. Additional options are in the [official cookbook](https://ocrmypdf.readthedocs.io/en/latest/cookbook.html).

OCRmyPDF uses Tesseract as its default recognition engine. I called Tesseract directly rather than through OCRmyPDF; for quality reference, see the comparison in Path 4. It handles most pages well and struggles on difficult ones.

Optional, untested by me: Mac users can try the [AppleOCR plugin](https://github.com/mkyt/OCRmyPDF-AppleOCR), which switches the recognition engine to macOS's built-in text recognition. It installs via pip (`pip install ocrmypdf-appleocr`, requires Python 3.11 or later) and is activated by adding `--ocr-engine appleocr` to the command (OCRmyPDF 17 or later required). OCRmyPDF works fine without it; if you want to try it, compare a few pages against originals before committing.

## Path 3: High Page Count, Cloud Upload Acceptable, Use Cloud OCR

Microsoft Azure, AWS, and Google all list cloud OCR at US$1.50 per 1,000 pages. Of the three, only Azure returns a searchable PDF directly, which is why I used it. One caution: Azure's official documentation does not state whether submitted data is used for training (see "Data Policies" later in this article). Following the rule from the opening section, verify with Microsoft or your organization before uploading sensitive documents; otherwise use a local path. The following reflects official information as of October 2026.

| Service | Cost | Free tier | Searchable PDF | Did I test it |
|---|---|---|---|---|
| Azure AI Document Intelligence Read model | US$1.50 per 1,000 pages ([pricing page](https://azure.microsoft.com/pricing/details/ai-document-intelligence/), [price API](https://prices.azure.com/api/retail/prices?$filter=productName%20eq%20%27Azure%20Document%20Intelligence%27%20and%20meterName%20eq%20%27S0%20Read%20Pages%27)) | Free plan (F0) analyzes only the [first two pages](https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/service-limits) per call | Returned directly, [no extra charge](https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/prebuilt/read) | Tested |
| [AWS Textract](https://aws.amazon.com/textract/pricing/) | US$1.50 per 1,000 pages | New customers: 1,000 pages per month for the first three months | Must assemble via code; official blog has an [example](https://aws.amazon.com/blogs/machine-learning/generating-searchable-pdfs-from-scanned-documents-automatically-with-amazon-textract/) | Not tested |
| [Google Document AI](https://cloud.google.com/products/document-ai/pricing) | US$1.50 per 1,000 pages | First tier (0 to 1,000) marked free; no indication whether per month or one-time | Official toolbox can convert output to [hOCR](https://docs.cloud.google.com/document-ai/docs/samples/documentai-toolbox-document-to-hocr) format; an additional step converts that to PDF | Not tested |

Steps for Azure:

1. Open a pay-as-you-go Azure account. A free trial may not be available; my account did not qualify.
2. Create a Document Intelligence resource and select the paid S0 tier. The free tier processes only the first two pages.
3. Find the Endpoint and Key on the resource page. The endpoint is the service URL; the key is a secret string that the code needs alongside the endpoint. Treat the key like a credit card number: do not hard-code it, do not share it, and do not paste it into an AI chat window.
4. Have a developer or an AI agent write a small program following the [official documentation](https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/prebuilt/read). Specify: use the Read model (prebuilt-read), API version 2024-11-30, include `output=pdf` in the analysis request. After submitting, poll for results every few seconds and download the PDF once the job is complete. The program should prompt you to enter the key at runtime, or read it from an environment variable you set in your own terminal. The key must never be displayed or written to disk. Run a 5-page trial first, open the downloaded PDF, search for a few words, and confirm the text layer is present before submitting the full batch.
5. Set a budget alert so you receive an email when spending reaches a threshold. Alerts send email by default; on their own, they do not disable the service or stop billing ([official documentation](https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/tutorial-acm-create-budgets)).

Two things tripped me up when opening the account. My account had previously been invited into another organization's space (Microsoft calls this a "directory"), and at login I was dropped into their space. It asked me to set up multi-factor authentication there; the SMS code arrived, but registration failed. Specifying that I wanted to sign in under my own account's directory resolved it. The key point is confirming which directory you are signed into. Multi-factor authentication is a security feature worth keeping active on your own account. The other issue: the billing page showed only "$" with no currency symbol, and I had to wait for the first charge to confirm which currency was being billed. A "$" on screen is not necessarily US dollars; clarify the billing currency before submitting a large batch.

For this run, the server-side processing of 600+ pages took 37 seconds, at a list price of roughly US$0.95. The bottleneck was transfer: the result file was 92 MB, and the download speed hovered at a few hundred KB per second, putting the download at around six minutes. The terminal sat completely still, and I briefly thought it had frozen. I am keeping this service active so the same script can re-run when new scans arrive.

## Path 4: Need to Read, Classify, and Catalog, Add AI Transcription

Have the AI transcribe each page verbatim; use that output for classification and coding. OCR handles searchability. Cross-check the two outputs page by page and flag any that diverge for human review. This is what I did. Here is how it went.

### The State of This Batch

Every page was an image, almost all black-and-white with 5 color pages. Typed body text, table figures, and checkboxes were legible. The difficulties were elsewhere: 3 pages were landscape content scanned in portrait orientation and needed a 90-degree rotation to read; page margins had handwritten stars and question marks; some headers were cropped, taking the dates with them; photos and charts had turned into halftone dots in the black-and-white scans.

The accompanying index was a starting point, but it came with a note that minor errors were possible. Working through the pages, I found a letter with a misdated entry in the index, a one-page-off split between two documents, two separator pages with handwriting that had been logged as blank, and one document noted as incomplete that was, in fact, complete.

The intended use was also fixed before I started: internal reading, searching, and tracing sources. Not for formal submission to outside parties.

### Why Split It into Two Separate Tasks?

Because "reading each page" and "making the PDF searchable" require different outputs, and different tools are suited to each.

The first task is AI page-by-page transcription. Each page image goes to a large language model (Claude, ChatGPT, or any AI that can read images and write text), with the instruction to transcribe it into structured text exactly as it appears: tables stay tables, checkboxes are marked as checked or unchecked, highlighting and handwriting are noted, and anything unclear or uncertain is flagged. This text is what feeds classification and coding, and it becomes the Word text version. Its limitation: it does not know where each word sits on the page, so it cannot be overlaid onto the PDF for searching or selection.

The second task is the OCR text layer. OCR records the position of each character on the page and lays an invisible layer of text over the image. That layer is what makes search and copy work. Its limitation: it does not understand content. Forms, handwriting, and rotated pages often come out as garbled strings.

The two outputs also serve a third purpose: checking each other. The two approaches work on different principles and tend to fail in different places. Comparing them page by page surfaces the pages worth a human look.

### How Were the Transcription Rules Set?

I picked the five hardest pages for a trial run: the cover, a page with highlighter marks, a form dense with checkboxes, a page of bold-and-italic Q&A, and a 90-degree-rotated table. After reviewing the results visually, only one cropped date was wrong. That cleared the way to submit all 600+ pages. The five key rules in the prompt:

- Transcribe verbatim. Reproduce typos as-is. Do not correct, summarize, translate, or add anything.
- Preserve structure: headings, lists, and tables.
- Flag checkboxes, highlighting, handwriting, and signatures with fixed markers.
- Include headers, stamps, and page numbers in place.
- Mark illegible text as such; write the most plausible reading for uncertain words followed by a question mark.

As will be seen, those markers are exactly what points to the places worth a second look.

<details>
<summary><strong>Full English prompt</strong> — expand if you are writing the code yourself</summary>

```text
Transcribe this scanned page into GitHub-flavored Markdown, verbatim.

Rules:
- Reproduce every printed word exactly as it appears, including typos, numbering, units, dates and punctuation. Do not correct, summarize, translate, reorder or add anything.
- Keep the structure: headings, numbered and bulleted lists, indentation levels, and tables (use Markdown tables). For complex forms, write one "Field label: value" line per field in reading order.
- Keep emphasis: **bold**, *italic*, <u>underline</u>.
- Checkboxes: [x] for checked, [ ] for unchecked.
- Highlighter marks: wrap the highlighted text in ==double equals==. Handwritten ticks or marks in margins: [handwritten mark].
- Handwriting: transcribe it if legible and prefix it with [handwritten]. Signatures: [signature].
- Fax headers, stamps, page numbers, headers and footers: include them on their own lines, in place.
- Illegible text: [illegible]. A word you are unsure of: write your best reading followed by [?].
- If the page is blank or nearly blank, output exactly: [blank page]
- Output only the transcription. No preface, no comments, no code fences.
```

Images were scaled so the long edge was at most 2,500 pixels and converted to grayscale JPEG before submission, to control per-page cost. Strikethrough was not in the prompt; the model marked it in GitHub Markdown style on its own.

</details>

### What Did It Actually Cost?

Additional usage fees came to roughly US$7, of which about US$6 went to AI transcription, working out to approximately US$9.6 per 1,000 pages, or about one cent per page. Cloud OCR ran at US$1.50 per 1,000 pages.

| Step | Tool | Volume and timing | Cost |
|---|---|---|---|
| AI page-by-page transcription | Claude Sonnet 5.5, batch submission (half price when results are not time-sensitive) | 600+ pages in 6 batches; all returned within 5 minutes | ~US$6.04 |
| Searchable text layer (first pass) | Tesseract (free, open-source OCR engine) | ~36 minutes on a 2-CPU cloud workspace | Software is free |
| Page orientation detection | PaddleOCR orientation model (free, open-source) | ~4 minutes | Software is free |
| Searchable text layer (second pass) | Azure Read model, returning a searchable PDF directly | 90 MB uploaded; server-side processing 37 seconds | List price ~US$0.95; charge pending |

These US$7 cover only usage fees billed by the two cloud services. They exclude my existing AI subscriptions (Claude for writing code, file assembly, and verification; Codex and Antigravity for review), and they exclude time. Anyone without these subscriptions, or who needs to hire a developer, should budget those costs separately. The free open-source tools also require someone who can install them and run commands.

Transcription is billed in tokens. Tokens are the unit AI services use to measure text and image volume; they do not map directly to pages or words. Sonnet 5.5 batch pricing is US$1 per million input tokens and US$5 per million output tokens ([official pricing](https://platform.claude.com/docs/en/about-claude/pricing)). This run consumed 3,189,072 input tokens and 569,843 output tokens, averaging roughly 5,000 input and 900 output per page, coming to about US$9.6 per 1,000 pages. Pages with more text or higher-resolution images cost more. To estimate your own file, run 5 pages and multiply. Anthropic says batches [typically complete within an hour](https://platform.claude.com/docs/en/build-with-claude/batch-processing); requests not processed within 24 hours expire and are not billed. This run came back in five minutes.

> **Key figures**
> - **AI transcription:** ~US$9.6 per 1,000 pages (~1 cent per page); 600+ pages ~US$6.04 (Claude Sonnet 5.5 batch)
> - **Cloud OCR:** US$1.50 per 1,000 pages; 600+ pages ~US$0.95; server-side processing 37 seconds
> - **Free OCR:** Tesseract software free; ~36 minutes including PDF-to-image conversion
> - **Elapsed time:** ~6 hours from download to finished second version, with an AI agent writing the code; not a first-timer's time estimate

Those 6 hours broke into four rough segments: trialing 5 pages and reviewing them, about 45 minutes; full-batch transcription and page-by-page comparison, about 45 minutes; building the first version of the archive after deciding to go that route, about 1 hour 10 minutes; opening the cloud account, running cloud OCR, and producing the second version, about 1.5 hours. There was a stretch in the middle where I was handling something else.

### How Much Better Is Cloud OCR Than Free Tesseract?

The medians look similar. The worst pages are where the gap opens up.

Claude used the AI transcription as a reference and measured how many characters from each OCR pass matched it. The comparison covers 557 pages with continuous body text:

| | Tesseract (free) | Azure Read (cloud) |
|---|---|---|
| Match rate (median) | 98.0% | 99.5% |
| Pages with more than 10% of characters diverging | 66 | 3 |
| Pages where it outperformed the other by more than 2 percentage points | 0 | 185 |

At the median, the gap is only 1.5 percentage points. Tesseract had 66 pages where more than 10% of characters diverged from the transcription; Azure Read had 3. All 185 pages where the two tools differed by more than 2 points went in Azure's favor.

This metric measures consistency between the two tools, not accuracy. The reference is the AI transcription, which can itself be wrong, so the comparison is most useful for identifying pages worth a human look at the original image. It also reflects a single batch of English typescripts; results for Chinese, vertical text, or heavily handwritten documents could be entirely different.

![Four-panel comic: Claude used the AI transcription as a reference and measured how many characters from each OCR pass matched it. The comparison covers 557 pages with continuous body text. Match rate (median): Tesseract (free) 98.0%, Azure Read (cloud) 99.5%. At the median, the gap is only 1.5 percentage points. Tesseract had 66 pages where more than 10% of characters diverged from the transcription; Azure Read had 3. This metric measures consistency between the two tools, not accuracy. It also reflects a single batch of English typescripts. The medians look similar. The worst pages are where the gap opens up.](/images/articles/scan-to-searchable-archive/01-worst-pages-en.svg)

On time: Tesseract, including PDF-to-image conversion, ran for about 36 minutes on a 2-CPU cloud workspace. Azure's server-side processing took 37 seconds.

### How Do the Two Outputs Check Each Other?

Compare page by page and pull out any that diverge, then look at each one. In this run, each side caught something the other missed.

**OCR caught a transcription gap.** After transcription, Claude ran a free-OCR pass over the full document and compared both outputs page by page. One page appeared in the transcription as a single header line, while OCR returned a full page of body text: the AI had dropped the entire page, yet the batch result showed success. That page was retranscribed against the original image. Without the OCR cross-check, this gap would have been nearly impossible to spot.

**Transcription caught OCR problems.** Two pages were handwritten forms. The free OCR turned them into garbled strings; the transcription went field by field through the handwritten content. The transcription also served as the ruler that made it possible to identify which 66 pages Tesseract handled worst.

**Transcription flagged its own uncertainties.** It marked two uncertain spots: one was a reference number with the final digit unread; the other was flagged as illegible. For the first, the cloud OCR returned the complete number with a confidence value of 0.948 (where 1 is highest); enlarging the original image confirmed it was correct. For the second, enlarging the original revealed a tracked-change annotation number that was sequential with others in the same document.

**Orientation detection is a hint, not a verdict.** The open-source orientation model flagged 7 pages as misaligned. Three were genuinely rotated; the other four had low confidence scores and turned out to be false positives on inspection. Thecloud OCR also reported non-zero angles on a few pages that simply had slightly slanted handwriting. Any page flagged by either tool deserves a quick look before deciding whether to rotate it.

### What Rules Does an Archive Require?

Set the rules before touching anything:

- **Codes:** Each group of documents opens with the date of those documents; within a group, sequence numbers follow that group's own list. Documents on the list that were not found in the scans still get a reserved code. About 20% of codes in this run were reserved this way. New arrivals slot in without disturbing existing numbers.
- **Originals untouched:** The received scans go into a dedicated folder, completely unmodified. Processed PDFs reuse the original images without recompression. Added elements sit outside the image: an invisible text layer, a narrow strip printed below each page carrying its code, and bookmarks. Each document gets a paired Word text file; the top level gets a master index noting gaps and discrepancies.
- **Separated folders:** PDFs, Word text versions, and original scans each live in their own folder, so opening the wrong file is harder.
- **Text versions labeled clearly:** Word files are convenient for searching and copying, but they can contain errors. Every Word file opens with a fixed line: "For citations, refer to the PDF or original scan."
- **Master index:** A single Excel file holding the document list, a text-verification score for each page, a record of missing documents and missing pages, differences from the original index, and a fingerprint (SHA-256 hash) for every file to confirm nothing changed in transit.

Before any of that work began, I sent the plan to two other AI tools (OpenAI's Codex and Google's Antigravity) and asked each to find problems, without either knowing the other was involved. Each flagged a dozen or so issues. Most of the rules above were either set or revised after that review round. Codex also caught the misdated letter in the index: the date was consistent across three places in the original document, meaning the index was wrong. The batch order was revised accordingly. Any factual claim it raised was verified against the original before I acted on it, following the same approach I described in [Getting Codex to critique Claude's work, without just taking its word for it](/en/articles/ai-second-opinion-independence).

### What Should Be Verified Before Handoff?

For anything being handed to others or kept for long-term archiving, check at least these:

- Every page has been assigned: to a specific document, as a separator page, or as a duplicate. Account for each page.
- The images inside the processed PDFs match the originals exactly, page for page.
- Every page is searchable. Spot-check a few by rendering the invisible text in red and overlaying it on the image; confirm the positions align. Rotated pages must be included in this check.
- The file list includes a fingerprint for each file. Recompute the fingerprints on the recipient's computer after transfer and confirm they match. Do not bundle Mac hidden files inside compressed archives.

All of these checks were run by code Claude wrote. For a personal archive you only need to search yourself, spot-checking a few pages against originals is enough. Verification code can also have bugs; this run produced one false failure, so when a check fails, inspect both the tool doing the measuring and the thing being measured.

## Are There Cheaper AI Transcription Options, or Free Open-Source Models?

Yes, though quality requires separate testing. The following reflects official unit prices as of October 2026. Sonnet is the only model I tested; the rest are rough estimates:

| Option | Official price (batch) | Per 1,000 pages (Sonnet is actual; others are estimates) | Notes |
|---|---|---|---|
| Claude Sonnet 5.5 | US$1 input / US$5 output per million tokens | ~US$9.6 (actual) | What I used |
| Claude Haiku 5.5 | US$0.05 input / US$0.25 output per million tokens | ~US$0.5 (estimate) | One-twentieth the price of Sonnet; untested, run a trial before switching |
| Claude Opus 5.5 | US$2 input / US$10 output per million tokens | ~US$19 (estimate) | Twice the price of Sonnet; untested |
| Gemini 3.1 Flash-Lite | US$0.125 input / US$0.75 output per million tokens | ~US$0.8 (estimate) | Untested; Google [lists](https://ai.google.dev/gemini-api/docs/deprecations) a shutdown as early as May 7, 2027 |
| Gemini 3.5 Flash-Lite | US$0.15 input / US$1.25 output per million tokens | ~US$1.3 (estimate) | Google's recommended replacement for 3.1 Flash-Lite; untested |
| Gemini 3.8 Flash | US$0.375 input / US$1.875 output per million tokens | ~US$2 (estimate); ~US$4 from 2027 | Prices double from January 2027, including batch pricing; untested |
| [Mistral OCR 4](https://mistral.ai/news/ocr-4) | US$4 per 1,000 pages, US$2 in batch | US$2 to 4 | Purpose-built document OCR, launched June 2026; untested |

Estimates assume output volume matches this run at roughly 900 tokens per page. Claude input uses this run's average of about 5,000 tokens per page. Gemini's PDF default is [560 tokens per page](https://ai.google.dev/gemini-api/docs/media-resolution), plus roughly 350 tokens of prompt. Gemini thinking tokens are also billed as output ([Gemini pricing page](https://ai.google.dev/gemini-api/docs/pricing)); that cost is not included in the table.

A lower unit price does not predict quality. Whether a cheaper model drops words or invents them can only be determined with your own documents: take those five hardest pages, run two models in parallel, compare every word against the original image, and then decide which to use for the full batch.

Open-source AI recognition models (olmOCR-2, PaddleOCR-VL, and similar) are free to license, but they require a GPU or time spent setting up a local environment. A benchmark from July of this year testing models on aged scans found that the top-scoring model passed fewer than half the evaluation criteria. One category in that benchmark rewards omitting letterheads and stamps, so anyone prioritizing verbatim preservation should read the per-category breakdown, not just the overall ranking ([original post](https://danielvanstrien.xyz/posts/2026/ocr-old-scans/)). Leaderboard positions are a starting point, not a verdict.

## What Do the Data Policies Actually Say?

For the three questions from the opening, here is what the two services I used officially state:

- **Azure AI Document Intelligence:** Submitted documents and analysis results are retained for 24 hours after processing completes, then deleted automatically. Early deletion is available via API call ([official documentation](https://learn.microsoft.com/en-us/azure/foundry/responsible-ai/document-intelligence/data-privacy-security)). Whether data is used for training is not stated on that page.
- **Claude API:** For commercial products, inputs and outputs are not used for model training by default ([Privacy Center](https://privacy.claude.com/en/articles/7996868-is-my-data-used-for-model-training)). Data is deleted from the backend within 30 days, with certain exceptions ([retention explanation](https://privacy.claude.com/en/articles/7996866-how-long-do-you-store-my-data)). Neither page says whether data can be deleted early. For batch processing, the [batch processing documentation](https://platform.claude.com/docs/en/build-with-claude/batch-processing) says requests and results are kept for up to 29 days and that you can call the API to delete a batch once it has been processed, but it does not say whether deletion removes the data immediately.

One more item turned up during research: AWS AI services may retain and use customer content to improve services, including for model training, and may store it outside your selected region. Textract is on [that list](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_ai-opt-out_all.html#ai-opt-out-all-list). Opting out requires an [AI services opt-out policy](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_ai-opt-out.html) through AWS Organizations. Anything not stated in official documentation is unconfirmed, not confirmed safe.

## Looking Back: A Better Order of Operations

Two steps could have been skipped:

- The first-pass Tesseract text layer was replaced by cloud OCR an hour and a half later. That first version was never delivered and went straight to the bin. If files can go to the cloud, starting with cloud OCR from the beginning saves a full round of file assembly and verification.
- Cloud OCR reports page angles directly. Using it makes the separate orientation-detection model unnecessary; just glance at any pages it flags before deciding whether to rotate.

A cleaner sequence: trial-run the five hardest pages and choose a transcription model, starting with a cheaper one. Hand the text layer to cloud OCR; use OCRmyPDF if files must stay local. Compare both outputs page by page and pull the pages that need a human look. Assemble and verify last.

## The Original Scans Were Never Touched

The original scans arrived and went into a dedicated folder in the archive, unmodified. Every processed PDF reuses those original images without recompression. Everything added sits outside the images: an invisible text layer, a narrow strip below each page printed with its code, bookmarks, a paired Word text file per document, a master index at the top level noting missing pages and differences from the original index.

Whichever path you take: keep a separate copy of the originals and do all processing on copies. The `--rotate-pages` and `--deskew` options in OCRmyPDF alter the page images in the output; what comes out may not match the original. When a new batch of scans arrives, assign codes by continuing the existing scheme and re-run the same script. More notes on tools and implementation are in [Creation & Enterprise: Tools and Implementation](/en/topics/startup/).