PDFBell

Free · No signup · No limits · Files never leave your browser

How to verify your files never leave your browser

You shouldn't have to take our word for it. These checks use only the developer tools already built into your browser and take a couple of minutes.

What you are actually testing

PDFBell's tools are JavaScript that runs inside the page you opened. When you pick a file, the browser hands it to that script in memory, libraries such as pdf-lib and pdf.js read and rewrite it, and the finished file is offered to you as a download created on your own device. If that is really how it works, no network request should carry your file's bytes while a tool runs.

That is a claim you can test rather than trust. Every modern desktop browser ships a Network inspector that lists each request a page makes, in both directions. The steps below show you how to read it, and which requests you will legitimately see so nothing surprises you.

Test 1: watch the Network tab

Use a file you do not mind experimenting with, ideally a large one. A 20 MB PDF makes an upload impossible to miss, while a one-page file could hide in the noise.

  1. Open any tool page, for example Merge PDF, in Chrome, Edge, Firefox or Safari.
  2. Open the developer tools: press F12, or Ctrl+Shift+I on Windows and Linux, or Cmd+Option+I on a Mac (in Safari, enable the Develop menu first in Settings > Advanced).
  3. Select the Network tab and clear the list. Turn on "Preserve log" so requests are not wiped if the page navigates.
  4. Filter by Fetch/XHR (Firefox calls it XHR). An upload of your file would have to appear here as a POST or PUT request, or as a request whose "Size" or "Transferred" column is close to your file size.
  5. Now add your file, run the tool and download the result.
  6. Look at the list again. You should see no POST or PUT request, and nothing close to the size of your file leaving your machine. Switch the filter back to "All" and sort by size if you want to double-check.

Which network requests are normal

A tool page is not request-free, and a clean test does not mean "nothing ever downloads". Everything below is data coming to your browser, not your file going out. The only requests are page assets, the engines and models listed here, and self-hosted fonts.

  • Page assetsThe HTML, JavaScript chunks, CSS and fonts for the page, all served from pdfbell.com. The fonts are self-hosted, so your browser does not contact a font provider.
  • PDF reading engineTools that show page thumbnails or read PDF content request /pdf.worker.min.mjs the first time a PDF is opened, and may also request files under /cmaps/ and /standard_fonts/ when a document needs them. These come from pdfbell.com.
  • Converter code, loaded on demandSome code is only downloaded when you use it, as separate JavaScript files from pdfbell.com: the Word reader for Word to PDF, the .docx writer for PDF to Word, the ZIP library when a result has several files, and the image decoders for HEIC and TIFF.
  • OCR engine and modelsOCR PDF downloads its engine when you start a run, all from pdfbell.com: a worker script of roughly 11 MB, a WebAssembly runtime, and the recognition models for the language you picked. The models total roughly 21 MB for English, Chinese and Japanese, or roughly 31 MB for French, German, Spanish, Portuguese, Italian and Dutch.
  • No third-party analyticsThe page makes no requests to analytics or advertising services. Everything you see in the Network tab comes from pdfbell.com. Because the site sits behind Cloudflare, Cloudflare's edge sees the same request metadata as any web host (IP address, user agent, URL, timestamp), but no analytics script runs in your browser.

Test 2: read the Content-Security-Policy

Every page PDFBell serves carries a Content-Security-Policy response header. Its connect-src directive lists the only origins that scripts on the page are allowed to send fetch, XHR or WebSocket requests to, and your browser enforces it.

To read it, open the Network tab, reload the page, click the first request (the page document), and look for content-security-policy under Response Headers. You should find connect-src limited to 'self' (pdfbell.com itself) and nothing else: no analytics or other third-party origin is allowed. The same policy limits images to the site itself plus data: and blob: URLs, which rules out the common trick of leaking data through an image request to another host.

This test shows where the page is allowed to send data. It does not by itself prove that pdfbell.com receives nothing, which is what Test 1 is for. The two together are stronger than either one alone.

Test 3: the offline test

The most convincing check is to cut the connection and run a tool anyway. If a tool still produces your file with the network off, the file cannot have been sent anywhere to be processed.

  1. Open the tool page and wait for it to finish loading.
  2. Load the engine files first. For tools that read or preview PDFs, add any PDF once so the PDF reading engine is downloaded, then remove it. For Word to PDF, PDF to Word, HEIC and TIFF tools, run them once on a tiny sample file so their code is fetched. For OCR PDF, run it once on a small page so the engine and the model for your language finish downloading.
  3. In DevTools, open the Network tab and set throttling to "Offline", or simply turn off Wi-Fi.
  4. Add your real file, run the tool and download the result.

Do not reload the page while offline: PDFBell has no offline mode and no service worker, so a reload needs the network. If a tool fails offline, open the Network tab and look at the failed request. It will be an engine file such as /pdf.worker.min.mjs, not your document. Browsers may also discard cached engine files, which is most likely with the large OCR models, so an offline failure there is inconclusive, while a success is conclusive.

The open-source libraries doing the work

These are the in-browser libraries the site actually imports. Licenses are as declared in each package's package.json; you can inspect all of them in the page's JavaScript sources in DevTools.

  • pdf-libMIT

    Creates and edits PDFs: merge, split, rotate, crop, delete and extract pages, sign, metadata, compress, and the PDF output of the converters.

  • pdfjs-dist (PDF.js)Apache-2.0

    Reads PDFs: page previews, PDF to PNG and JPG, text extraction, PDF to Word, and page rendering for OCR.

  • @paddleocr/paddleocr-jsApache-2.0

    Text recognition for OCR PDF. The PP-OCR models it loads are also published by the PaddleOCR project under Apache-2.0.

  • onnxruntime-webMIT

    Runs the OCR models as WebAssembly inside your browser.

  • mammothBSD-2-Clause

    Reads .docx files for Word to PDF.

  • docxMIT

    Writes .docx files for PDF to Word.

  • heic2anyMIT

    Decodes iPhone HEIC photos for HEIC to PDF.

  • utifMIT

    Decodes TIFF scans for TIFF to PDF.

  • JSZipMIT or GPL-3.0-or-later (dual-licensed)

    Bundles several output files into one ZIP download.

What these checks do and do not prove

They show what your browser does on the visit you test. A website can change its code between visits, so repeat the test whenever a document is sensitive enough to matter. For the highest-stakes files, going offline first, as in Test 3, removes the question entirely.

For the written version of our commitments, read the Privacy Policy. If a test ever shows something that contradicts what this page says, please tell us through the contact page.

Read the Privacy PolicyBrowse all toolsContact us