Privacy workflow
What actually happens to your PDF when you compress it online?
The important question is not only whether a PDF gets smaller. It is where the file goes, who can see it, and what changes when you choose email delivery, a share link, AI review, or support.
2026-06-06 - 7 min readCompression should start in the browser
For normal BitePDF compression and editing, the working file stays in the browser while you compare original size, output size, readability, and page choices. That is the right default for resumes, school forms, receipts, client packets, and admin paperwork.
The product should be honest when compression is not useful. If a generated output is larger or too blurry, the safer answer is to keep the original, extract pages, or use a link workflow instead of pretending the export improved.
Email delivery is a choice, not the default storage model
A download can stay local. Email delivery is different: if you ask BitePDF to email a finished export, the file has to travel through the email provider to reach the signed-in address. That is useful for receipts and handoff, but it should not be treated like private vault storage.
For sensitive documents, local download is usually the calmer path. If support needs to understand a bug, a screenshot and workflow details are better than sending the private PDF.
Share links solve a different problem
A share link is not the same as local compression. Creating a link means the selected file is uploaded so a URL can exist. That is useful for large client handoffs, ZIP files, and files that are awkward to attach, but the link should be treated as something other people may access if they receive it.
The decision is simple: use local compression when the file just needs to fit a portal; use a link only when the handoff itself is the problem.
The agent should reduce what it sends
An agent can be useful without receiving everything. BitePDF's remote planner can work from a typed request, page counts, byte sizes, selected pages, workflow settings, and optional visible-page context. Raw filenames and full PDFs should not be needed for most planning.
That is also how owner notifications should work: tell the operator that an export failed, which route failed, which workflow was active, and whether a customer needs billing review, without including customer email addresses, file names, PDF text, or attachments.
What to send support
Good support context is specific but not private: the workflow, target size, browser/device, whether the result was visible before checkout, and the exact button or step that failed.
Bad support context is unnecessary exposure: card numbers, passwords, passport numbers, student IDs, full legal packets, or private PDFs. If a reproduction file is needed, make a safe dummy file that shows the bug without exposing the real document.