I built a parallel OCR engine that makes scanned PDFs searchable - entirely in your browser.
OCR is slow because most tools process pages one at a time. A 500-page scanned textbook means waiting through 500 sequential operations.
So I built PDFyre's OCR differently - it's a parallel processing engine.
How it works:
- Your PDF is split into chunks, and pages are processed concurrently across multiple threads - not one page after another
- Multiple Tesseract.js OCR workers run at the same time, so a 500-page book uses every core your machine has instead of idling on one
- The recognized text is embedded back as an invisible, word-aligned layer - so the PDF becomes fully searchable and copy-pasteable
The privacy angle matters here: because everything runs in your browser, the whole document - even a 100+ MB scanned book - never leaves your device. No uploads, no server, no "processing on our secure servers" promise that means your files end up on someone else's machine anyway.
Why parallel? Because the files that need OCR are the biggest ones. Textbooks, contracts, archived records - all hundreds of pages. Processing them sequentially in a browser would be unusable. With parallel workers, the 890-page book that inspired this project gets OCR'd in minutes.
Features:
- 100+ languages (English, Hindi, Arabic, Chinese, Japanese, Russian and more)
- 5 quality modes - from Fast (150 DPI) to Lossless (PNG)
- Word-level text alignment, original images preserved
- Free, no accounts, no file size limits, no watermarks
Try it - your file never leaves your browser: https://pdfyre.xyz
Love that it's in the browser. I built something similar for building resumes in public; it is hard but worth it.
Handling OCR entirely client-side in the browser is impressive for privacy and server costs. Are you using Tesseract.js / WebAssembly under the hood? Great work!
This is a really useful solution, especially for students, researchers, and anyone working with large scanned documents. The parallel processing approach sounds much faster than traditional OCR, and the fact that everything runs locally in the browser makes it even better from a privacy perspective. Supporting multiple languages without uploads, accounts, or watermarks is a big plus too.
This is a really interesting approach to a problem that’s easy to underestimate. The combination of parallel processing and browser-based OCR makes a lot of sense, especially for large documents where traditional sequential processing becomes painfully slow. The privacy-first angle is also a strong differentiator. Great example of solving a practical problem by rethinking how the underlying process works.
Running the OCR in the browser is the product. People will pay to keep a scan off someone else's disk.
The use case that jumps out immediately: regulated-industry professionals — legal, finance, healthcare. GDPR and data sovereignty requirements mean a lot of those teams explicitly cannot use cloud OCR on client documents, full stop. They're either stuck with expensive enterprise licenses or doing painful manual work. Browser-only processing solves that compliance problem completely.
The privacy framing is right, but I'd sharpen the positioning: "client-side OCR" can sound like a technical detail, while "your documents never leave your machine — guaranteed, by architecture" is a compliance promise that lands differently with the specific buyers who will actually pay for it.
Practical question for your go-to-market: who are your first 10 paying targets? Freelance lawyers and accountants can be faster to close than enterprise procurement cycles, and they typically have exactly the document volume where the parallel processing makes a visible difference.
Free and local reads as a consumer pitch, but the file never leaving the device is actually a procurement pitch, and that is where the money is. Every law firm, clinic, and accounting practice I have dealt with has a rule against uploading client documents to a third-party server, and your architecture removes their vendor security review entirely. I would build a page aimed at exactly those buyers and charge for a team version before optimizing another millisecond of OCR speed.
The privacy angle is the real differentiator here, not just the speed. Most "free" OCR tools bury a server upload in their flow somewhere, and most users never check. Browser-only processing for a 100+MB file is a genuinely hard technical constraint to work within, not just a marketing line.
Curious how you're handling memory with parallel Tesseract workers on a 890-page book client-side — did you hit browser memory ceilings during testing, or does chunking keep it manageable?
The 890-page example makes the performance problem easy to picture. Curious how much the processing time changes across different machines and document types.