/guides/local-processing
Local processing, explained.
This guide is for people who need to merge, split, compress, or read files without sending the document to a website. It describes the current ZANCTA tools, not a cloud conversion service.
Why local processing
Upload-based PDF sites send the file to a server so that server can rewrite it. That is convenient, and it also means the operator, their processors, and anyone who obtains those logs can see the document. ZANCTA’s implemented PDF and image tools read the file you selected in the browser and write the result in the browser. The bytes for those workflows are not posted to ZANCTA for processing.
What still leaves the device
The application itself is downloaded like any website: HTML, JavaScript, fonts, and images. Analytics, if you allow it, may record that a tool finished — with the tool name only. Accounts, email, and payments (when live) send account and billing data to those providers. None of that is a substitute for uploading the PDF.
OCR
Image OCR runs English recognition in a Worker with bundled language data. It is meant for photographs or scans of English text. Handwriting, dense tables, tiny type, and non-English scripts will fail or produce garbage. The recognized text is not sent to an OCR API.
Start at OCR.
PDF text extraction
PDF Text Extractor copies text that is already embedded in a text-native PDF. A scanned “PDF” that is only images has no such text; the tool reports that instead of inventing words. It is not OCR for PDFs. For scans, render pages to images with PDF to images, then use OCR on those images if you accept the English-only limit.
Start at PDF Text Extractor.
Images and metadata
Compression, conversion, and resize stay in the browser for JPG, PNG, and WebP. HEIC and SVG are out of scope. EXIF cleaning removes common metadata from supported images; it cannot prove a downstream site will not re-tag a file you later upload elsewhere.