OCR It: Pin a Region, Hotkey Through a Book, Feed Your LLM Offline

You found a 400-page course reader, a Kindle trading book, or a slide deck trapped in a viewer that will not let you select text. Copy-paste returns nothing. Screenshotting every page by hand is not a workflow. Pasting images into Claude one at a time is worse.

OCR It is a Chrome extension for that gap. Pin a rectangle once. Hit a hotkey on each page — or start an auto-run that captures, OCRs, turns the page, and stops when the document ends. Export a .txt file and hand it to an LLM. Everything runs locally with bundled Tesseract. No API key, no network, no install-time site access.

Thiago Lima (@thiagotigaz) open-sourced it as ocr-it on GitHub. It hit the Hacker News front page on August 24, 2026 (~89 points) because the problem is universal and the privacy posture is unusually strict for an AI-adjacent tool.

TL;DR

Why this exists in the LLM workflow stack

RAG pipelines assume you already have extractable text. Mistral OCR and cloud document APIs solve extraction at scale — for a price and with upload. OCR It sits at the opposite corner: one human, one tab, one book, privacy preserved.

The author’s stated use case is feeding Kindle finance books into an app to compare strategies against code. That is the same pattern as any “I need this corpus in context” job — except the corpus was never selectable.

The irony the README acknowledges: an AI-adjacent tool that never talks to a server — because the pages you capture are often exactly the ones you do not want to ship to a third party.

How to use it (minimal path)

1. Install — clone github.com/thiagotigaz/ocr-it, chrome://extensions → Developer mode → Load unpacked.
2. Pin shortcuts — chrome://extensions/shortcuts. Defaults: ⌥⇧R redraw region, ⌥⇧S capture once, ⌥⇧A auto-run.
3. Draw the region — inside the text block margins; headers and page numbers in the box get read too.
4. Capture or auto-run — single hotkey queues OCR in the background; auto-run waits for each page’s OCR before turning (so end-of-document detection works).
5. Export — Copy all or Download .txt with --- page N --- separators. Edit bad pages in the popup; re-OCR individually.

For file:/// PDFs, enable Allow access to file URLs on the extension’s Chrome details page.

Practitioner setup: auto-run on a paginated reader

The README’s happy path is a web reader where text is rendered but not selectable — Kindle Cloud Reader, institutional ebook portals, or internal slide viewers. The fiddly part is next-page advance, not the OCR itself.

Step-by-step for auto-run:

1. Open the document at page 1. Zoom until the text block fills the viewport consistently — you will not resize mid-run.
2. Press ⌥⇧R and drag a rectangle inside the body text margins. Exclude headers, footers, and page numbers if you can; anything inside the box becomes part of the transcript.
3. Open the OCR It popup → Auto-run settings → pick how the extension turns pages:
   • Point click — click the “next page” arrow once; the extension stores screen coordinates. Works across iframes and shadow DOM because it is not a CSS selector.
   • Keyboard dispatch — if the reader responds to arrow keys, route the key event into the frame that owns the capture region.
4. Grant site access from the popup when prompted. activeTab covers one-off captures; auto-run needs persistent permission on that origin.
5. Set a page cap (start with 10) and run ⌥⇧A. Watch the first few pages: thumbnails and confidence scores appear per page in the popup.
6. When the run stops — duplicate text detected, cap hit, or advance failed — skim low-confidence pages, edit inline, or re-OCR individual crops before export.

Chrome PDF viewer workaround: capture works; auto-advance does not. Use arrow keys manually between ⌥⇧S presses, or export the PDF through a tool that renders pages in a normal tab first. For DRM-heavy readers, OCR It cannot bypass copy protection — it only reads pixels you can already see on screen.

Feeding an LLM: paste the .txt into Claude, ChatGPT, or a local stack. For RAG ingestion, split on --- page N --- markers and chunk by section rather than dumping 400 pages into one prompt — OCR noise compounds across long context windows (context pricing makes that expensive anyway).

What is technically interesting

Three design choices matter beyond “OCR in a browser”:

MV3 offscreen document. Service workers cannot run Tesseract. Cropping, greyscale upscaling, and OCR live in src/offscreen/ while background.js handles hotkeys, a serial OCR queue, and the run loop.

Next-page control as a point, not a selector. DOM re-renders invalidate CSS selectors. A fixed (x, y) reaches cross-origin iframes and shadow roots — routing across frames was the fiddly part (postMessage offsets when origins differ; window.screenX inside an iframe lies about frame position).

Auto-run waits for OCR before turning. A timer-only loop sails past the last page and fills the transcript with duplicates. Waiting for each page’s text is what makes duplicate detection and clean stop conditions work.

The test suite drives real headless Chrome over CDP — including cross-origin iframe and open shadow DOM fixtures — because Chrome 137+ ignores --load-extension and headless cannot show optional permission prompts.

Limits (read before a 300-page run)

• Chrome’s PDF viewer — capture yes; auto-advance no (plugin sandbox).
• Fixed rectangle — resize or zoom mid-run breaks alignment with the stored region.
• Screenshot rate limit — Chrome caps captures; fast mashing queues with backoff.
• Accuracy follows the source — crisp UI text is easy; scans need human cleanup before you trust an LLM summary.
• Cross-origin iframe readers — grant the site from the popup before auto-advance; activeTab alone is not enough.

HN’s top accuracy question: is Tesseract still best in 2026? For offline, private, good-enough text on rendered pages, OCR It’s choice is coherent. For historical scans or handwriting, commenters pointed at EasyOCR, RapidOCR, or a local vision model — same tradeoff as cloud OCR vs self-hosted pipelines.

OCR It vs cloud and local alternatives

OCR It wins when the bottleneck is “I can see it but I cannot select it” and you refuse to upload. It loses when you need layout-aware extraction at scale — that is where document AI APIs and multi-vector RAG earn their keep.

What people are asking on HN

“Why not just use a vision model?” — You can, one screenshot at a time, if you accept upload and per-image cost. OCR It optimizes for serial pagination with zero egress: the extension is a capture harness, not a model zoo.

“Does this work on Kindle?” — The author’s stated use case is finance books in a web reader. Any paginated viewer where pixels render works; auto-advance quality depends on whether you can click or key the next page reliably.

“Is 93–95% confidence good enough?” — For summarization and search, usually yes if you spot-check. For legal or numeric tables, treat OCR like unverified model output — human review on high-stakes pages.

“What about anti-AI fonts or Ghost Font?” — Those target vision models and scrapers, not offline Tesseract on static crops. If a publisher obfuscates text at the pixel level, no OCR engine reads it cleanly without manual cleanup.

What to do with the export

Treat the .txt like any other unverified corpus:

1. Skim confidence and thumbnails in the popup before you paste 200 pages into a chat.
2. Ask structured questions — summaries, search, compare to your codebase — not “assume this OCR is perfect.”
3. Do not become a meat proxy — if you forward the export without checking obvious garbage pages, your colleague becomes the OCR QA department. Spot-check tables and numbers twice.

For a broader local stack — models, inference, workflows — see build your own personal AI system.

Related on explainx.ai

• Build your own personal AI system — local models and workflows
• Mistral OCR 4 — when cloud extraction beats local Tesseract
• RAG vs agentic RAG — structure-aware retrieval
• Meat proxy — do not forward unread AI (or OCR) to coworkers
• When answers get cheap, trust is the job
• Context window pricing decoded
• Baidu Unlimited-OCR — open-weight document parsing
• Ghost Font — when vision models miss motion-encoded text

Sources

• OCR It — GitHub (MIT)
• Hacker News thread — August 24, 2026
• Author comment on rendered-text accuracy (~93–95%) and Kindle finance use case

Extension behavior, hotkeys, and limitations reflect the README and HN discussion as of August 25, 2026. OCR quality varies by source; verify before high-stakes use. Follow @explainx_ai for local-tool coverage.