PDFyre
Superfast parallel OCR with unlimited pages, free and local
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
I'm a med student and I built a PDF tool that never sees your files
I'm in medical school, and during exam season I got an 890-page scanned textbook. It was useless - no search, no copy-paste. Ctrl+F found nothing because there was no text, just pictures of pages.
Every free OCR tool I tried either capped the file size (mine was 132 MB) or wanted me to upload a book full of personal notes to their server.
So I built PDFyre - powered by a parallel processing engine that runs everything in your browser. It splits your document across multiple threads, processes dozens of pages at once, and uses every core your machine has. The 890-page book that started it all got OCR'd in minutes, all on-device.
How the engine works:
- Splits PDFs into chunks and processes pages concurrently across threads
- Multiple OCR workers run at the same time, not one page after another
- Zero uploads - the whole engine runs locally, so even 100+ MB files stay on your device
What it does:
- OCR PDF - make scanned PDFs searchable (100+ languages)
- Merge PDF / Split PDF / Compress PDF
- Rotate PDF / PDF to Images / Images to PDF
- Free, no accounts, no file size limits, no watermarks
Stack: PDF.js, pdf-lib, Tesseract.js - all client-side, orchestrated by the parallel engine.
Why it exists: Most PDF tools profit from your documents. PDFyre doesn't - it's privacy-first.
Looking for: feedback on the tools, the UX, and honest thoughts on whether privacy-first PDF tools are something you'd use.
Try it (free, nothing uploaded): https://pdfyre.xyz
-
1
This is such a practical problem to build around. An 890-page textbook is exactly the kind of file where browser-based, parallel OCR and zero uploads make a real difference.
The privacy-first angle is especially compelling too. Most people don’t think twice about uploading documents until those documents contain personal notes, research, or sensitive information.
Would be interesting to see how PDFyre handles especially large or image-heavy PDFs across lower-end devices.
9 Comments
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.