PDFyre

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.

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.