ekaanhub
Blog

Check it yourself

Last checked 6 September 2026

Every tool site says it respects your privacy. You have no way to tell which ones mean it. So rather than ask you to believe us, here is how to check. Three tests: the first needs no technical knowledge at all, and the last one needs no browser.

The claim being tested

When you use a tool on EkaanHub, your file is opened, processed and saved back by your own browser. It is never sent to us. We do not receive it, cannot see it, and have nothing to delete afterwards.

Test one: pull the plug

This takes about thirty seconds and needs nothing but the device you are reading on.

  1. Open any tool — Compress PDF, Merge PDF or Crop Image will do. Let the page finish loading.
  2. Turn off your wi-fi, or switch the device to aeroplane mode. Genuinely disconnect it.
  3. Now add a file and use the tool.

It works. The file is processed and you can save the result, with no internet connection at all. A tool that uploaded your file could not do this — there would be nowhere for the file to go.

Try the same three steps on any site that asks you to upload. They stop at step three. That difference is the whole point.

Test two: watch the network

The first test shows the tool does not need the network. This one shows it does not use it. You will need your browser’s developer tools, which are built into every desktop browser.

  1. Open a tool page, then press F12 on Windows, or Cmd + Option + I on a Mac. In Safari, switch on the Develop menu in Settings, under Advanced, first.
  2. Click the Network tab. Leave it open.
  3. Click the clear button so the list is empty. Everything after this is caused by what you do next.
  4. Add your file and run the tool.

The list stays empty. Not “a small request” or “an encrypted one” — nothing at all. When we ran exactly these steps on 6 September 2026 with a 0.66 MB PDF, adding the file produced zero requests, and processing it produced zero requests.

If you want a second signal, look at the size column. Uploading a file means sending its bytes, so a 10 MB document cannot leave your machine without 10 MB appearing there. Nothing on our tool pages sends a body larger than a couple of kilobytes, and most send none at all.

Test three: read the header, run nothing

The two tests above ask you to run an experiment and trust that the result generalises. This one does not. Most tool pages here are served with a rule that tells your browser to refuse any attempt by the page to send data anywhere at all — to us or to anyone else. Your browser enforces it, not our code, and you can read it without loading the page:

curl -I https://ekaanhub.com/compress-pdf

Look for connect-src 'none' in the content-security-policy line. That is the browser being instructed to block every upload, every background request, every analytics ping — including to our own servers, which is the part that matters, because our own server is exactly where a file would go.

It is worth understanding why no site that processes your file on a server can do this. The moment they add that rule, their own tool stops working: the upload it depends on is the first thing the browser refuses. We can only publish it because there is nothing to upload.

Five tools do not carry it, and we would rather list them than have you find them: PDF to Text, PDF to Word and PDF to Excel download recognition data for scanned pages, and Edit PDF and Watermark PDF download a font when you type in Hindi or another Indian script. Those are downloads coming to you. Your file still stays put — and on those five pages, tests one and two are how you check it.

What you will see, so it does not surprise you

The Network tab is not silent when the page first loads, and a page claiming otherwise would be lying. Load a tool and you will see roughly fifteen to twenty requests. Every one of them is the page itself: the HTML, the stylesheets, the JavaScript that becomes the tool, and the fonts. They all come from ekaanhub.com — we host our own fonts rather than pulling them from Google, so there is no third-party request in that list.

Those requests happen before your file exists as far as the page is concerned. That is why the clear step matters: it separates loading the tool from using it.

Two honest exceptions:

  • If you accepted analytics when the banner asked, you will see requests to Google Analytics on the blog and the other pages of this site. That is tracking, it is real, and it is why we do not claim to be tracking-free. It stays off unless you agree — decline it, or ignore the banner, and it never loads. It does not run on the tool pages at all now, because the rule in test three forbids it there, and we would rather lose the measurement than weaken the rule. Details are on the cookies page.
  • The text recognition tool downloads its language data from a public CDN the first time you use it, because that data is large and we do not ship it with the page. You will see those requests. They are downloads coming to you — your image is still read and processed on your own device, and is not part of them.

One part you can read

Everything above shows you what the code does without showing you the code, and there is a fair objection to that: minified JavaScript is not the same as source you can read. Our site’s source is not public, and we are not going to pretend otherwise.

One module is public: pdf-redact, published at github.com/pkaur1130/pdf-redact under AGPL-3.0, is the code behind Redact PDF — the same file that runs on this site, not a demonstration written for the occasion. It is published because redaction is where the difference between doing this properly and appearing to do it actually matters: most tools draw a black rectangle over words that are still in the file, and people have leaked the exact thing they were hiding that way.

The test worth reading is the adversarial one. It redacts a document, reads the text back out of the file, and asserts the secret is gone. Clone it and run npm test yourself.

What this does not prove

We would rather state the limits than have you find them. These tests show what the code you have loaded right now does. They do not prove anything about code we might publish next month — for that, you would have to check again. And apart from the one module above, our source is not public, so for the rest you are verifying behaviour rather than reading the implementation.

That is a real gap and we are not going to talk around it. What we can say is that the behaviour is checkable by anyone, at any time, in under a minute, using tools already on your computer — which is more than most of this category offers.

What does reach us

Being straight about the other direction: three things do leave your device, and none of them is a file you opened in a tool.

  • The pages themselves, which your browser has to fetch to show you anything.
  • Anonymous usage counts, but only if you agreed to analytics. No file names, no file contents, nothing personal.
  • Whatever you type into the contact form, if you choose to write to us.

The full account is on the privacy page, which is written from what the code does rather than from a template.

Found something that contradicts this?

Tell us, and we will fix the page or the code — whichever turns out to be wrong. Write to us. A screenshot of the Network tab is the most useful thing you can send.