Security

1. Client-side processing in the browser

Most OptimaPDF tools operate on a zero-trust architecture — your file never leaves your device. We use WebAssembly and JavaScript to process PDF files directly in your browser. This means that even we, as service operators, have no access to your files. This applies to: merge, split, rotate, watermark, page-numbers, crop-pdf, edit-pdf, sign-pdf, redact-pdf, flatten-pdf, delete-pages, extract-pages, reorder-pages, add-page, metadata, pdf-to-svg, pdf-to-epub, pdf-to-txt, fill-form, pdf-to-images, to-pdfa, compare-pdf, unlock-pdf, and protect-pdf.

2. TLS/SSL encryption

All communication between your browser and our server is encrypted using TLS 1.3 (Transport Layer Security). We use an SSL certificate issued by a trusted certificate authority. This means that data transmitted over the internet is unreadable to third parties. You can verify the certificate validity by clicking the padlock icon in your browser's address bar.

3. Content Security Policy (CSP)

We enforce a strict Content Security Policy (CSP) that restricts the execution of scripts from untrusted sources. CSP prevents Cross-Site Scripting (XSS) attacks, code injection, and data theft. Our CSP policy is regularly audited and updated.

4. RAM-only processing

For tools requiring server-side processing (compression, OCR, format conversions), files are processed exclusively in the server's RAM. Files are not written to the hard drive, not copied to backups, and not replicated. Once the operation completes, the file is immediately removed from memory. Maximum server retention time: a few seconds.

5. File verification

• Magic bytes verification — before processing, we verify that the uploaded file is actually a PDF by analyzing its header (%PDF). This prevents file-type spoofing attacks.
• File size limit — maximum upload size is 100 MB. This protects against both server overload and potential DoS attacks.
• Integrity check — we verify that the file is not corrupted before starting processing.

6. Attack protection

• CSRF protection — we use anti-CSRF tokens and Origin/Referer header verification to prevent Cross-Site Request Forgery attacks.
• Rate limiting — we limit requests from a single IP address, protecting against brute-force and DoS attacks.
• HTTP Security Headers — we apply X-Content-Type-Options (nosniff), X-Frame-Options (DENY), Strict-Transport-Security (HSTS), and Referrer-Policy headers.
• Input validation — all input data is validated on both client and server side, preventing injection attacks.

7. Zero data storage

We do not store your files or personal data on the server. We do not require registration, login, or email address to use the tools. We do not create user profiles or track your activity between visits.

8. AI feature security

AI features use the external OpenRouter API. Your API key is stored exclusively in your browser's localStorage — we have no access to it. Text sent to OpenRouter is limited to content extracted from the PDF. We do not send user-identifying data, IP address, or browser information. OpenRouter uses TLS encryption and does not use submitted content for AI model training.

9. Dependency security

We regularly update all libraries and dependencies used in the project. We use automatic vulnerability scanning tools (npm audit, Snyk). All critical vulnerabilities are patched within 48 hours of CVE publication.

10. Vulnerability disclosure

If you discover a security vulnerability in OptimaPDF, please responsibly disclose it by emailing kontakt@optimapdf.com. We commit to:

• Acknowledging receipt within 24 hours.
• Performing analysis and taking corrective action within 14 days (depending on severity).
• Informing the reporter about actions taken.
• Not pursuing legal action against those who responsibly disclose vulnerabilities.

11. File transmission security

In the rare cases where a file must be sent to the server (server-side tools), transmission occurs over encrypted HTTPS using TLS 1.3. The file is transmitted in memory (streaming) without temporary disk storage. After receiving the response, the file is immediately removed from server memory. We do not keep logs of file operations.

12. Standards compliance

We adhere to the following security standards and recommendations:

• OWASP Top 10 — protection against the most common web application vulnerabilities.
• GDPR — personal data protection in accordance with EU Regulation 2016/679.
• CERT Polska guidelines — following recommendations from the Polish CERT team.
• Mozilla Observatory — we aim for an A+ rating in HTTP headers security test.

13. Encryption at rest and ISO 27001 / SOC 2 certification

Most operations on your files happen entirely in your browser and never reach any server — so there is no "data at rest" on our side to encrypt in the first place. For the few tools that do require server-side processing (see points 4 and 11), the file exists only in the server's RAM for a few seconds and is deleted immediately after the operation completes — it is never written to disk, backed up, or stored in a database, so "encryption at rest" doesn't meaningfully apply here. We do not hold formal ISO 27001 or SOC 2 certification. These are expensive, multi-year audit programs designed primarily for organizations that maintain persistent customer data stores, operational processes, and multi-person teams; in an architecture where the server never retains user data at all, most of the controls these certifications cover simply have no subject to apply to. Instead, we rely on the alternative, source-verifiable guarantees described in points 1–12 above (zero storage, encrypted transit, CSP, attack protections, a public vulnerability-disclosure process).

14. eIDAS and Qualified Electronic Signatures (QES)

The "Sign PDF" tool offers a PAdES digital-signature mode (an Advanced Electronic Signature) using your own certificate (.p12/.pfx) — the entire operation runs locally in your browser; your file and certificate are never uploaded to a server. This is a real cryptographic signature, not just a visual image of one. Important caveat: this signature is NOT automatically a Qualified Electronic Signature (QES) under the EU eIDAS regulation (910/2014) — QES status depends entirely on whether your certificate was issued by a Qualified Trust Service Provider (QTSP) on a Qualified Signature Creation Device. Issuing such a certificate and verifying its holder's identity inherently requires an external, licensed third party — this is the one part of the process that cannot be done 100% locally, without a server. If your certificate is qualified, a PAdES signature made with it meets the requirements of QES; if you use a self-signed or corporate certificate, you create a legally valid advanced electronic signature, but not a qualified one. Check the legal requirements that apply to your specific use case.