Security starts with keeping local files local.

For supported local workflows, file bytes are read and transformed in your browser. They are not intentionally uploaded to PDFSwipe. The browser, operating system, extensions, network, and device remain part of the security boundary.

Account functions use Firebase Authentication and a Firebase-backed control plane for identity and service state. That account data is separate from local PDF bytes.

• Email-based authentication with verification requirements for account sessions.
• Server authorization intended to fail closed for disabled cloud processors.
• Firestore rules intended to isolate account data and deny unspecified client collections.
• HTTP-only, secure production session cookies with same-site protection.

These controls are a development foundation, not a certification or guarantee.

Before accepting server uploads, PDFSwipe must add content-signature validation, malware scanning, resource and timeout limits, isolated workers, decompression-bomb defenses, signed flows, short retention, output validation, rate limits, logging, and tested deletion paths.

Before API or MCP access, it must add scoped credentials, revocation, idempotency, quotas, abuse monitoring, confirmation rules, and an auditable contract.

Do not send confidential documents in a support request unless a secure upload path is provided. Report suspected issues through Contact with the affected URL, reproduction steps, and non-sensitive evidence.

We will update this page when processing modes, authentication providers, payment providers, storage, or public integrations change.