The most important security property of WorkWithPDF is architectural: your file contents are processed locally in your browser and are never transmitted to our servers. This page explains what that means in practice and how the rest of the system is secured.
1. Local-Only File Processing
All PDF operations — merging, splitting, compressing, converting, redacting, signing, annotating — run inside your browser using WebAssembly compiled from the same libraries used in server-side tools. Your files are loaded into browser memory, processed there, and the result is written directly to your device as a download.
No file content, filename, page count, or document metadata is included in any network request during a tool operation. You can verify this independently at any time:
- Open your browser DevTools (F12 on most browsers)
- Go to the Network tab
- Process any file with any tool
- Observe that no request contains your file data
2. What Leaves Your Device
The following data is sent over the network when you use WorkWithPDF:
- Page load requests — HTML, JavaScript, CSS, and WebAssembly bundles are fetched from our CDN when you first visit. These are static assets with no user data.
- Anonymised analytics events — tool name, browser type, and country (IP not stored). No file content. See our Privacy Policy for full details.
- Authentication requests — if you sign in, your session token is verified with Clerk. Your documents are not involved.
That is the complete list. Nothing else leaves your device during normal use.
3. Redaction — Visual Cover
The Redact PDF tool draws solid black rectangles over the regions you specify. This is a visual cover: the output PDF contains black boxes over the target areas. For most practical purposes this is sufficient, but it is not equivalent to cryptographic content removal. If your use case requires guaranteed content erasure at the byte level, you should use a dedicated forensic redaction tool and treat WorkWithPDF's redaction as a presentation layer.
4. Account and Authentication Security
Accounts are managed by Clerk, which provides:
- Password hashing with bcrypt
- Email verification on sign-up
- Session token rotation
- Brute-force protection
We do not store passwords or session secrets ourselves.
5. Data in Transit
All network traffic between your browser and our servers uses HTTPS (TLS 1.2 minimum, TLS 1.3 preferred). This applies to page loads, analytics, and authentication requests.
6. Infrastructure
WorkWithPDF is hosted on Vercel. Static assets are served from a global CDN. We do not operate persistent file storage for user documents — because documents never reach our infrastructure, there is no document store to secure or breach.
7. Device ID (Free Tier)
The free tier limit of 3 documents per device is enforced using a random identifier stored in your browser's local storage. This ID is not linked to your identity and is never transmitted to our servers in association with file content. Clearing your browser storage resets it.
8. Responsible Disclosure
If you discover a security vulnerability in WorkWithPDF, please report it privately to gaurav@stipple.sh before disclosing it publicly. We will acknowledge receipt within 2 business days and aim to resolve confirmed issues within 30 days. We do not operate a formal bug bounty program at this time but will credit researchers who report valid issues.
9. Contact
Security questions or reports: gaurav@stipple.sh
Stipple AI Pty Ltd, Australia