Trust and security at PDFAmend

Your PDF stays in your browser.

PDFAmend processes document files and edits on your device. Our application servers verify paid access, but they do not need the PDF file or its text to authorize your download.

What that means in practice

• PDF processing happens locally in your browser.
• Payment card details are handled through Stripe-hosted Checkout.
• Paid exports are authorized by server-side entitlement checks.
• Access links and session tokens are time-limited, revocable and stored as cryptographic hashes.
• No account password is required to edit and preview.

Technical architecture

How editing, payments, and access control fit together.

Client-side PDF processing

Parsing, rendering, text edits, redaction, and export assembly run in your browser (PDF.js + pdf-lib). Application servers do not need the PDF file or its text to authorize a paid download.

Server-authoritative entitlements

Purchase state, remaining exports, and plan windows are resolved on the server. The browser may cache UI state, but paid export authorization is checked server-side before a download unlock is granted.

HttpOnly session cookies

After checkout or restore, session credentials are delivered in HttpOnly cookies so ordinary page scripts cannot read them from document.cookie.

Hashed tokens

Access links and session secrets are stored as cryptographic hashes. Presenting a valid raw token proves possession; the database holds the hash, not a reusable plaintext secret.

Stripe webhook verification

Subscription and payment lifecycle updates are accepted only after Stripe signature verification. Entitlements are synced from verified events, not from client-supplied “paid” flags.

Postgres Row Level Security

Entitlement and session tables are backed by Postgres with Row Level Security policies so database access follows least-privilege rules for the application role.

Transport security (HTTPS/TLS)

Production traffic is served over HTTPS/TLS. Browsers negotiate encrypted connections to the application and to Stripe Checkout.

Security headers

Responses are configured with defense-in-depth HTTP headers. We only list controls that ship with the application configuration.

• Strict-Transport-SecurityEnabled in production deployments to prefer HTTPS.
• X-Content-Type-Optionsnosniff — reduces MIME sniffing risk.
• Referrer-Policystrict-origin-when-cross-origin.
• Permissions-Policycamera, microphone, and geolocation disabled.
• Content-Security-PolicyIncludes frame-ancestors 'none' (and related browser framing protections).
• Cache-Control: no-storeApplied on entitlement APIs under /api/access/* and /api/team/*.

What we do not claim

Honest boundaries matter more than marketing badges.

• SOC 2, HIPAA, FedRAMP, or ISO certification
• End-to-end encryption or a zero-knowledge architecture for all product data
• That the service is “unhackable” or immune to all threats
• That infrastructure providers never see request metadata (they operate the network path)

Data handling

What moves where during normal editing, checkout, and restore flows.

Infrastructure providers

PDFAmend runs on third-party infrastructure. Vercel hosts the application, Stripe processes payments, Postgres (via our database provider) stores entitlement and session records, and Resend may send transactional email. Those providers can see operational metadata needed to run their services (for example request logs or payment records). They do not receive your PDF file contents as part of the edit/export path described above. Their own privacy and security policies apply to data they process.