What happens to a file from selection to download, which work stays on the device, and where the limits of browser processing apply.
Data-flow map
The path is short: selection → file-signature check → browser memory → decoding → bounded processing → output check → download. Exact Size Tools does not send the selected file to an application server during these operations.
Images: browser decoder and canvas, followed by a downloadable file whose format and dimensions are checked
PDFs: a local library loaded from this site, followed by a new PDF whose header and page count are checked
Temporary previews: object URLs revoked when replaced or cleared
Logs and optional analytics: selected file details are never included; Google services load only after visitor consent
Safety limits
Byte, pixel, file-count, and page-count limits reduce the chance that a damaged or unusually large file will exhaust browser memory. The tool checks the file signature before decoding it and stops on unsupported, corrupt, encrypted, or infeasible input. These controls reduce avoidable risk, but they are not a substitute for keeping an untouched original or using a trusted device.
A signature is a format identifier, not an antivirus scan. Decoding still uses device memory.
Image output
Actual encoded type, decoded output dimensions, and the selected byte rule
A technical pass cannot assess identity, document validity, or receiving-portal acceptance.
PDF output
PDF header, reload through the local library, and page count
Interactive features and signature validity need separate review.
Metadata-only DPI
Density tags in JPEG or PNG
Other metadata remains, potentially including location information.
The page and its libraries are downloaded from the host. The selected-file processing code does not send the selected file to a server. Optional advertising and analytics are separate third-party scripts; essential-only mode keeps them unloaded. Downloads saved by you remain on your device until you remove them.
To inspect the behavior, open your browser Network panel, choose essential-only, clear the request list, and process a non-sensitive test image. Code downloads are expected; no file-upload request is used by the processing workflow.
Check the local-processing claim with a sample
You can inspect a processing run without using a personal file. This check is for the core tool workflow; optional services and the initial page download have separate network behaviour.
Open the compressor and choose “Keep essential only” when the optional-services prompt appears.
Load its synthetic sample. This downloads a public sample file; it is not an upload of your file. Wait until the settings appear.
In a desktop browser’s developer tools, open the Network panel. Clear the log after the sample has loaded, then process it. Inspect any requests and their payloads. The processing workflow should not send the selected file bytes to a server.
As a second check, switch the Network panel to Offline after the first sample run has completed. Process the sample and download the result. Restore normal networking afterward.
For a PDF task, the PDF library loads on first processing. Complete one sample run online before trying an offline repeat. Reloading a page while offline is a different test and is not promised to work.
What this check does not establish
An offline run is evidence about that loaded workflow, not a complete security audit or a guarantee about browser extensions, the device or future site versions. Your browser, operating system and anything you do with a saved download remain outside the tool’s control. Use the public samples whenever you are checking behaviour.