Your files never leave your device.

Something you can check yourself in 30 seconds.

The short version

Your PDF opens and gets edited on your own computer, inside this browser tab. The file is never sent to us, so there is nothing for us to see, store, or lose.

You don't have to take that on trust. The site ships with a rule your browser itself enforces that blocks this page from sending your file anywhere. Even a bug on our side couldn't get it out.

The quickest check: open the editor, turn off your Wi-Fi, and keep working. Everything still runs, because none of it ever needed the internet. The technical proof, and ways to verify it from outside, are further down this page.


Where your file goes

A quick map of what happens to a file you open here, and the one case where a request touches our server.

What you doWhere your file goes
Edit, merge, split, sign, and the page toolsStays in your browser. Nothing is uploaded.
Compress, OCR, and convert filesStays in your browser. The engines run locally as WebAssembly.
Recent files and unsaved-work recovery in the editorKept in your browser on this device only, so you can reopen and recover work. Never uploaded. Clear it anytime.
Sign in, license, and contact formA request goes to our server, but it never carries your file.
Future opt-in paid features (cloud AI, advanced OCR, high-fidelity conversion)Would send your file to a server, clearly labeled first, and only if you choose them.

What we do (and don't) collect

The pages themselves are static HTML, JS, and CSS, served from Cloudflare. In front of them runs one small Cloudflare Worker: it hands out those files, keeps a daily count of page views, and handles sign-in, licensing, and the contact form. It has a key-value store behind it for exactly those things — accounts, licenses, and counts. What it does not have is any endpoint that accepts a file. There is no analytics script on the page either (the CSP would block one anyway). The hosting provider logs basic request metadata like IP address, user agent, and response status, for the usual reasons: abuse mitigation and traffic shaping. That metadata never includes PDF content, because PDF content never reaches the host in the first place.

We do like to know, roughly, how many people use the site. We get that from the same Cloudflare request logs described above, read back as aggregate daily totals on our own infrastructure. There is still no analytics script, no cookie, and no beacon on the page. Open your developer tools and you'll see the page make no such request; the same Content-Security-Policy that blocks an analytics script blocks one here too. We keep only per-day counts (never a raw IP, never a per-visitor record), build no profiles, and don't track you across other sites. And because we set no tracking cookies and build no cross-site profile, there’s no consent banner to click; the only thing kept on your device is your own recent files, which you can clear anytime.

If you sign in, we store an account record: your email, the ID your sign-in provider gives us, and any license IDs. Buying a pass adds a billing record — the Stripe customer and subscription IDs, which pass it was, and when it runs out. Each sign-in also keeps a session row: when it started, when it was last used, and a copy of your browser's user-agent string (capped at 200 characters), which is what lets you tell your sessions apart and revoke them from the account page. That is the whole list. No record of which tools you open, no device fingerprints, no profile built from your behavior.

Stored on your device

The editor keeps a private, on-device copy of your recent files and any unsaved work in your browser's local storage (IndexedDB). It's what powers the Recent files list and crash recovery, so a closed tab or a browser crash doesn't cost you your work. That copy lives only in this browser on this device. It is never uploaded, and the same Content-Security-Policy above still blocks anything from sending it anywhere.

You stay in control: clear recent files anytime from the editor’s start screen, or clear this site’s data in your browser to wipe everything at once. Only a handful of the most recent documents are kept, older ones are dropped automatically, and private/incognito windows keep nothing after you close them.

For the technical reader

Proof rather than promises: how the block is enforced, how to check it yourself, and independent scanners. Each section expands.

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 allows fetch, XHR, and WebSocket requests only to discreetpdf.com itself, and there is no endpoint there that accepts your file. Account, license, and contact actions make same-origin requests too, but they only ever carry credentials and form text, never your file's contents. Even if a future bug or a bad dependency tried to send your PDF out, the browser would block the request before it left your device.

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:; frame-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 discreetpdf.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.
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 discreetpdf.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, because they're what the browser enforces. Check them directly:

curl -sI https://discreetpdf.com/ | grep -i policy
Check this site with independent scanners

Every claim on this page can be checked from outside. These scanners are run by third parties, not by us, and each link runs a live scan against discreetpdf.com:

  • securityheaders.com: grades the HTTP response headers, including the Content-Security-Policy shown above.
  • HTTP Observatory: MDN's header and TLS scanner, run by Mozilla.
  • SSL Labs: inspects the HTTPS/TLS configuration in depth.
  • Blacklight: The Markup's privacy inspector; it looks for ad trackers, third-party cookies, and session-recording scripts.
  • security.txt: how security researchers can reach us (RFC 9116).

Read next

All PDF tools

All free, all in your browser. Pick the task you need.