Text PDF vs Scanned PDF for Offline AI

The difference is inside the file

Two PDFs can look identical on screen while containing very different data. A text PDF stores characters and layout instructions that a parser can extract. A scanned PDF may store one image per page with no useful character layer. To a reader they both show words; to a local document system one contains text and the other contains pixels.

PDF.js describes itself as a platform for parsing and rendering PDF files and separates its core parsing layer from its display and viewer layers. [1] Rendering a page is not the same as extracting accurate reading order. A document can display perfectly while its text layer is missing, scrambled, or arranged in an order that does not match how a person reads the page.

This distinction determines the workflow. Text extraction can be fast and fully local. Image-only pages need optical character recognition, which analyses pixels and predicts characters. OCR adds computation, language data, possible preprocessing, and another source of error before an AI model sees any words.

How to tell whether a PDF has usable text

The quickest test is selection. Open the PDF, drag across a sentence, copy it, and paste it into a plain text field. If the sentence appears in the right order, the page probably has an extractable text layer. If selection highlights the whole page as one object, produces nothing, or pastes nonsense, treat it as a scan or a broken text layer.

Search is another useful check. Use the PDF viewer's Find command for an unusual word that is visibly present. A match suggests searchable text. No match does not prove the page is an image because fonts, encodings, ligatures, or security settings can interfere, but it is a warning.

Test more than the first page. Some documents mix generated pages with scanned appendices, signatures, receipts, or forms. A local AI app should report page-level extraction rather than labelling the entire file from one successful page. It should also distinguish an empty page from an extraction failure.

• Copy and paste a complete sentence.
• Search for a distinctive visible term.
• Check a page with columns, a table, and a footer.
• Inspect appendices or inserted scans.
• Confirm the extracted text keeps headings and paragraphs in a sensible order.

What OCR adds and where it fails

Optical character recognition converts images of writing into machine-readable text. Tesseract is an open-source OCR engine with language data and page-segmentation options. Its documentation and research history make clear that recognition is a separate process from displaying the source image. [2]

OCR quality depends on the scan. Low resolution, blur, compression artifacts, faint ink, skew, shadows, decorative fonts, handwriting, and mixed languages can reduce accuracy. Page segmentation also matters. A system that assumes one uniform block may read a two-column page across both columns, join unrelated labels, or place a footer inside a paragraph.

Tables are particularly difficult because recognising the characters does not reconstruct the logical relationships among rows, columns, merged cells, and notes. A receipt may yield all visible numbers but associate a price with the wrong item. Mathematical notation, chemical formulas, code, and diagrams require more than general text OCR.

Offline OCR also needs local resources. The application must have the OCR runtime and appropriate language packs before the connection disappears. Processing many high-resolution pages can consume battery, memory, storage, and time. An honest app should show OCR progress and identify failed pages instead of quietly indexing an empty document.

Extraction, chunking, and retrieval

After text exists, a document AI system usually divides it into chunks, creates a searchable representation, retrieves passages for a question, and includes selected passages in the model prompt. Each stage can lose context. A heading may be detached from its paragraph, a table row may split across chunks, or a footnote may appear beside the wrong claim.

The model does not automatically see the whole PDF. On a phone, sending every page into every prompt would be slow and memory-intensive. Retrieval selects a limited set of passages, so a relevant answer can be missed if extraction, chunking, or search fails. A citation proves which passage was supplied, not that the passage was extracted correctly or that the model interpreted it correctly.

Good local document tools preserve page numbers and source ranges through the pipeline. The user should be able to open the cited page and compare the answer with the original. Highlighting only generated prose without a source location is not a meaningful citation.

Where document answers can go wrong

A private offline document workflow

First, prepare the app while online. Install or cache its shell, download a compatible model, and obtain any OCR language pack needed for scanned pages. Activate the model and confirm it remains selected after restart. An offline claim is meaningful only when all required components are present.

Import one document and inspect what the app reports. It should identify page count, extraction status, indexing progress, and whether OCR was used. If a file contains sensitive information, confirm that import, parsing, OCR, indexing, retrieval, and inference all stay on the device for the selected workflow. Optional web search or reporting should be separate and explicit.

Ask a question with a known answer, then open the citation. Compare names, dates, numbers, negations, and table relationships with the original page. Repeat in airplane mode with a new question. If the app cannot explain whether a page was extracted or OCR-processed, do not assume a fluent response is grounded.

1. Classify pages as extractable text, image-only, or mixed.
2. Install OCR resources before going offline when scans are present.
3. Preview extracted text from a simple page and a difficult page.
4. Wait for indexing to complete and note failed pages.
5. Ask a factual question and open every citation.
6. Test again in airplane mode with a fresh question.
7. Delete the document and confirm its local index and attachments are removed.

Privacy does not end at upload

A promise that a PDF is not uploaded is important, but it is not the whole privacy assessment. Local copies, extracted text, thumbnails, OCR output, embeddings, search indexes, chat excerpts, backups, and crash logs can all contain sensitive information. Deletion should cover derived data as well as the original attachment.

Browser storage is origin-scoped and controlled by the user agent. web.dev notes that IndexedDB can store structured records and binary blobs, while users can still clear storage and browsers can apply quota or persistence rules. [3] A PWA should therefore offer a clear backup and deletion model instead of implying that browser storage is permanent.

If a document workflow offers online search, sharing, or response reporting, the interface should preview exactly what will leave the device. The default local question-answering path should not silently transmit retrieved passages to make a result look better.

How CuriousLM handles local files

CuriousLM is designed to parse, index, retrieve, and discuss supported local files on the current device. Imported content belongs to a local project and ordinary document questions use the selected local model. Citations should lead back to the relevant file location so the user can verify the answer rather than trust generated prose alone.

Support still depends on the file. A text PDF can be extractable while a scan may require OCR capability that is not present for the current surface or language. Complex tables, handwriting, damaged files, and visual diagrams may need manual review or a different tool. CuriousLM should state those limits rather than fabricate confidence.

Model downloads, application updates, optional search, and confirmed reports remain network actions. Deleting a project or attachment should also remove its derived local index according to the product's deletion contract. The practical privacy test is the full document lifecycle, from import through answer verification and deletion.