How PDFcraft Processes Files Locally in Your Browser
When you select a document in PDFcraft, the application reads its bytes in your browser and uses client-side libraries to generate the output. There is no PDF-processing upload backend in this architecture. That is a statement about document processing, not a claim that the page makes no network requests.
From selection to download
Select a file
The browser exposes the selected file to the application. The tool reads its contents into memory; selecting a file does not itself mean uploading it to a processing server.
Load and run the required library
Many page operations use pdf-lib. Protect and Unlock use qpdf WebAssembly, while PDF-to-image and Grayscale use PDF.js and canvas rendering. Some components are downloaded when the tool is used.
Generate an output
PDF tools generally create bytes and expose them as a browser download through a Blob/object URL. PDF-to-image uses encoded image data URLs. The application may hold inputs, previews, and outputs in memory during the operation.
Save and review
Download the result yourself. Browser downloads and any later sharing are separate from the processing step. Keep the original until you have verified the result.
Which external requests are expected?
Protect and Unlock request the qpdf WASM runtime from jsDelivr. PDF-to-image and Grayscale configure a remote PDF.js worker on jsDelivr. The site also loads its own pages and scripts. AdSense advertising resources load only after an accepted consent choice; declining keeps core tools available. Request and connection data are separate from the document bytes processed by the application.
Local storage and cleanup are not secure erasure
The consent choice is stored in browser localStorage when available. The application releases generated object URLs and processing resources through its cleanup paths, but this is not a forensic erasure guarantee for browser memory, caches, or downloaded files. Delete Pages is visible page removal, not secure redaction or sanitization.
Local execution does not guarantee semantic preservation
Grayscale rasterizes each page while preserving its intended physical dimensions. It does not preserve searchable/selectable text, links, forms, bookmarks, signatures, or other document semantics as such, and output may grow. Compress performs structural/object-stream optimization rather than explicit image downsampling. Check the particular tool, not just where it runs.
How to inspect the behavior yourself
Use a non-sensitive test file. Open your browser’s developer tools and network panel before loading the page, preserve the request log, then run one tool. Inspect request destinations and payloads and distinguish resource downloads from document transfers. Check accepted and declined advertising choices separately. Observing one session does not prove every possible future script behavior; it gives evidence for the session you tested.
Practical limits
Large files, many pages, and high-resolution raster rendering can require substantial memory. Processing can fail or the tab can become unresponsive. A tool that downloads a runtime may not start without network access. Offline availability and performance are not guaranteed.
Read the relevant details
Frequently asked questions
Are document contents sent to a PDFcraft processing server?
The inspected application architecture processes them locally and has no PDF-processing upload backend.
Does that mean there are no external requests?
No. Website resources, remote qpdf WASM and PDF.js workers, and consent-dependent advertising can generate network requests.
Does releasing an object URL securely erase a document?
No. Resource cleanup is not a promise of forensic erasure of browser memory or downloaded files.
Can I use every tool offline after opening the homepage?
No such guarantee is made. Some tool runtimes load when processing starts.