Why your PDF editor shouldn't need an upload

The upload step you never think about

Open almost any free PDF website, and the first step is the same: drag your file into a box, wait for a progress bar, and only then does an editor appear. That progress bar is your file leaving your device and landing on someone else's server.

It's such a familiar pattern that it stopped looking strange a long time ago. But think about what's usually inside the PDFs people edit this way: signed contracts, salary slips, admit cards, income certificates, bank statements, medical reports, passport scans. Documents people would never paste into a random website's text box — yet they'll drag the PDF version of the same information in without a second thought, because the upload box feels routine.

What actually happens after you upload

Depending on the service, your file is typically stored temporarily on a server, processed there (text extracted, pages rendered, edits applied), and then served back to you as a download. Most reputable services say they delete the file after a short window — an hour, a day. That claim is usually true. But it still means:

• Your document existed, even briefly, on infrastructure you don't control
• It transited the open internet twice — once up, once back down
• You're trusting a privacy policy you probably didn't read, on a free tool whose business model you don't fully know
• If the service logs metadata, runs analytics, or has a breach, your document was exposed to that risk window

None of this makes these tools malicious. Most aren't. But it's an unnecessary risk for something that doesn't need to carry any risk at all.

The alternative: editing that never leaves the browser

Modern browsers can do far more than render pages. Libraries like pdf.js (Mozilla's own PDF renderer, the same engine behind Firefox's built-in PDF viewer) and pdf-lib can parse, render and rewrite a PDF's binary structure entirely in JavaScript, running on your machine, inside the tab you already have open. No server round trip is required at any point.

That's the entire architecture behind Plate. When you open a file, your browser reads the bytes directly from disk using the File API, decodes the PDF structure locally, and renders it to a canvas you can click and edit. When you click Download, the edited bytes are reassembled locally and handed to you as a new file. The network tab in your browser's dev tools will show no request carrying your document, because none is made.

Why don't more tools work this way?

Partly history: browser-based PDF manipulation libraries matured relatively recently, and a lot of existing tools were built server-first and never rearchitected. Partly business model: a server-processed file is easier to meter, rate-limit, and gate behind a paywall — if your edits happen in someone else's infrastructure, they control what you're allowed to do and how often. A tool that runs entirely in your browser has a much harder time selling you tiered limits, because there's no server quota to enforce.

Plate doesn't have a paid tier, so there was never a reason to route your file through a server in the first place.

A quick checklist for choosing a PDF tool

• Check the network tab before you trust a tool with a sensitive document — see above.
• Read what the privacy policy actually says about retention, not just the marketing copy on the homepage.
• Prefer tools that work offline once loaded — a strong signal that nothing is being sent out.
• Be extra careful with ID documents, admit cards, financial statements — these are exactly the files worth the ten extra seconds to check.