Two processing models
Client-side processing runs the transformation on the user’s device, typically in browser JavaScript, WebAssembly, Canvas, Web Crypto, or other web APIs. Server-side processing uploads input to an application or third-party service that performs the work on remote infrastructure.
The visible “Choose file” control does not reveal which model is used. A page can read a local file into browser memory without uploading it, or it can immediately send that file in a network request.
How the data flow differs
Client-side: file → browser memory → local library/API → download
Server-side: file → network → remote processor/storage → network → download
Local processing can reduce exposure to a conversion backend and eliminate server retention for the transformation itself. Server processing can use more memory and CPU, centralize complex native software, and continue after a tab closes.
Practical trade-offs
| Question | Client-side | Server-side |
|---|---|---|
| Large files | Limited by device/browser memory | Limited by upload and server quotas |
| Network | Processing may work after code loads | Input and result require transfer |
| Performance | Depends on user device | Depends on server capacity and queue |
| Retention | May remain only in page memory | Requires a stated storage/deletion policy |
“Runs locally” is not the whole privacy story
A locally implemented transformation does not mean the entire webpage makes no network requests. Advertising, analytics, fonts, error reporting, security checks, or newsletter forms may communicate separately. Browser extensions, clipboard managers, a compromised device, and files you later upload elsewhere remain outside the transformation’s privacy boundary.
Conversely, server processing is not automatically unsafe. Relevant questions include encryption in transit, authentication, access controls, subprocessors, retention duration, deletion, logging, jurisdiction, and incident handling.
How to evaluate a tool’s claim
- Read the tool-specific privacy statement rather than a generic homepage badge.
- Check whether the workflow names a remote API or account requirement.
- Use browser developer tools to inspect network requests during a test with non-sensitive data.
- Distinguish the processing request from unrelated site services.
- For sensitive or regulated data, follow organizational policy even when processing is local.
Examples on YesFreeTool
The reviewed image resizer, PDF compressor, JSON comparer, and JWT inspector implement their core operations in browser code. Each tool page documents its own libraries, memory behavior, output, and limitations; this guide does not make a blanket claim about every site feature.
For a concrete document workflow, continue with how PDF compression works.