FreeOCR.AI Desktop v0.5.0: PDF Batches That Survive Interruptions

PDF OCR no longer waits for an entire document before returning anything. Each page is rendered, submitted, and stored on its own, so results arrive as they are recognized instead of at the very end.

That changes what failure means. A slow page or a dropped request now affects one page, not the whole file. Temporary errors are retried automatically, and the file list shows exactly how many pages have been recognized.

For a short document this is barely noticeable. For a scanned contract, a product manual, or a long report, it is the difference between waiting and starting over.

When a batch is interrupted, the file does not fall back to failed. It moves to Needs attention, keeping the pages that already succeeded.

• Continue processing resumes from the first unfinished page, for the whole batch or for a single file.
• Export completed pages saves what is already recognized and marks the rest as not recognized, so you can use the result immediately.
• Discard releases the saved progress for that file if you no longer need it.

Clearing a list that still has resumable progress now asks for confirmation first. Exported files are never removed—only the unfinished batch state is.

One boundary worth knowing: resuming applies to an interruption within the current batch list. Closing the app clears the list, but anything already exported stays on disk.

Billing follows the same page-by-page logic. Each page is charged when it is submitted, and a page that fails is refunded automatically. Resuming a paused file only checks the credits needed for the pages that remain, not the whole document again.

If credits run out mid-batch, Desktop opens the top-up page directly. After payment, refresh your balance and continue from the same point.

This per-page model applies to PDF recognition. Image batches keep their existing behavior.

A document that large is a different test. Because pages are processed one after another, a 1,700-page file is a long run rather than a quick job. Plan for it: keep the app open, make sure your remaining pages are covered by credits, and let resume handle interruptions. If you only need part of the document, export the completed pages and stop there.

Tables are the harder half. Recognized tables are kept as HTML table structures, and Word export preserves merged cells and spanning headers. But a 1,700-page PDF full of rotated scans, multi-line headers, and tables that break across pages is still a recognition problem, not a scheduling one.

If you need spreadsheet-ready rows and columns from images, image table extraction is the right tool today. Table extraction for PDFs is still in development.

That is the honest boundary of this release: interruption is solved, scale is manageable, and table fidelity on very large documents is the next problem to solve.

The visible changes needed some less visible work. API requests now go through the app's Go HTTP client instead of the webview. WebKit can keep a half-open connection after a network change, and aborting a request does not close it, so every retry reuses the same dead connection. The Go client drops its pool on a transport error, which means a retry actually reconnects.

v0.5.0 also updates to Wails v3.1.0 and keeps a single PDF document open at a time, so a stalled render cannot exhaust the PDF worker.

Smaller improvements in this release:

• Failed images can be retried without leaving the batch.
• Manually scrolling a long file list no longer fights automatic scrolling.
• Sidebar labels more clearly separate text recognition, table extraction, and data extraction.
• Added Polish and Ukrainian; Desktop now ships 14 languages.