How Client-Side Processing Saves Your Data (And Our Server Costs)
A transparent look at why ImagePDF.Tools processes files in the browser — the privacy case, the business case, and the engineering trade-offs.
When I built ImagePDF.Tools, I made a deliberate decision to process all files client-side. I want to be transparent about why — because it's genuinely the right thing to do for users and the right decision for the business model.
The Privacy Argument
Most free image tools are funded by advertising, and advertising revenue scales with data. Your uploaded files — even if deleted after processing — provide valuable signals: document types, file sizes, usage patterns, geographic distribution. That data has monetisation value even when the files are nominally deleted.
When you drop a file into ImagePDF.Tools, the bytes travel this far: from your filesystem into your browser's memory. That's it. No CDN logs, no server-side processing logs, no database write containing your content. There is literally no mechanism for us to see what you processed.
The Business Case (It's Also Cheaper)
Server-side processing requires significant infrastructure:
- ●Compute instances sized for burst load (image processing is CPU-heavy)
- ●Object storage for temp files (even 1-hour retention multiplied across thousands of users)
- ●CDN egress costs for delivering processed files back to users
- ●Compliance infrastructure: GDPR deletion pipelines, audit logs, breach notification systems
- ●Security surface: every server that touches user files is a breach liability
Our backend consists of three Edge Functions: a Stripe checkout endpoint, a billing portal endpoint, and a webhook handler. Total infrastructure cost is a few dollars per month — regardless of processing volume. Every user brings their own CPU.
The pngquant and Ghostscript algorithms are computationally expensive. But that cost runs on your CPU, not ours. Client-side processing is both more private and more scalable.
Engineering Trade-offs
- ●WASM bundle size: pngquant WASM is ~350 KB. Mitigated with
rel="prefetch"— loaded silently after initial render. - ●Mobile performance: A 20MP phone photo can take 3–5 seconds on a mid-range Android. Web Workers keep the UI responsive; a progress indicator manages the wait.
- ●Browser compatibility: OffscreenCanvas and WASM are in all modern browsers. IE11 (<0.3% global traffic in 2026) is not supported.
- ●Memory limits: Browsers cap JavaScript heap size. Files above ~100 MB are unreliable. We enforce this limit on uploads.
What We Do Store
- ●Clerk (auth): your email address, account creation date, and plan tier. No file content.
- ●Stripe (billing): payment information for Pro subscribers — held entirely by Stripe.
- ●Vercel (hosting): standard HTTP access logs (IP address, request path). These are page load logs, not file content.
Verify It Yourself
- 1.Open any tool on ImagePDF.Tools
- 2.Open Chrome DevTools → Network tab → filter by "Fetch/XHR"
- 3.Drop a file into the tool
- 4.Watch the Network tab — zero requests carry your file data
The only requests you'll see are page navigation, the AdSense script (for free-tier users), and the Clerk session token check. Your file bytes appear nowhere. Try it yourself.
Ready to try it?
All tools run entirely in your browser — no uploads, no account required.
Try the Tools