Your files never leave your browser.

How the claim is enforced

The site ships with a Content Security Policy header that tells the browser exactly where the page is allowed to send data. The relevant directive is connect-src 'self' — it permits fetch / XHR / WebSocket requests only to editpdfsfree.com itself, which is a static host with no upload endpoint to send to. Even if a future bug or a malicious dependency tried to exfiltrate your PDF, the browser would block the request before it left your machine.

The full header, served on every page:

Content-Security-Policy: default-src 'self'; script-src 'self' 'wasm-unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' blob: data:; font-src 'self' data:; connect-src 'self'; worker-src 'self' blob:; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'

Verify it yourself

1. Open this page in any browser.
2. Open DevTools (F12) and switch to the Network tab.
3. Filter by Fetch/XHR.
4. Open the editor and drop in a PDF. Edit it, save the result.
5. Watch the Network panel: every request you see is a static asset from editpdfsfree.com. Your PDF's bytes never appear in any outbound request, ever.

Other security headers

Defense in depth. Each of these is verifiable by inspecting the response headers on any page of the site:

• Strict-Transport-Security — forces HTTPS for two years across all subdomains; prevents a network attacker from downgrading the connection to serve a tampered version of the site.
• Cross-Origin-Opener-Policy / Cross-Origin-Embedder-Policy — isolate the page in its own browser process so other tabs can't read its memory.
• X-Frame-Options: DENY + frame-ancestors 'none' — block other sites from embedding this one in an iframe, which defeats clickjacking attacks that could trick you into uploading a file to a hostile wrapper.
• Referrer-Policy — limits the data leaked to outbound links to just the origin, never the full URL.
• Permissions-Policy — explicitly denies camera, microphone, geolocation, and federated tracking cohorts.

What we do (and don't) collect

The site serves static HTML / JS / CSS from Cloudflare. There is no application server, no database, and no analytics scripts loaded on the page (the CSP would block them anyway). The hosting provider logs basic request metadata — IP address, user agent, response status — for the standard reasons (abuse mitigation, traffic shaping). That metadata never includes PDF content because PDF content never reaches the host.

Pass buyers have an account record (email, license IDs, sign-in provider claim). That's the entire shape of what we store about you — no usage logs, no device fingerprints, no profile data.

Pass sign-in uses Google or GitHub OAuth

The free editor remains untouched by any third party. When you sign in to activate a pass, you authenticate with Google or GitHub. They see that you signed into editpdfsfree.com and hand us your verified email plus a stable account ID. We don't request additional scopes, don't pull your contacts, your repos, or anything else. Sign-in is only required to use pass-unlocked features; everything below the paywall stays anonymous.

Source of truth

If anything on this page disagrees with the actual _headers file the host ships, the headers win — they're what the browser enforces. Check them directly:

curl -sI https://editpdfsfree.com/ | grep -i policy