Are Online PDF and Image Tools Safe? How to Check Whether a Site Uploads Your File

Some are and some aren't, and you don't have to take the site's word for it either way. Most free PDF and image tools upload your file to their server, do the work there and send the result back. A smaller group does the work inside your browser, so the file never leaves your computer. You can find out which kind you're using in about two minutes with tools your browser already has.

This guide shows that check, what a "files are deleted after one hour" promise actually covers, and when uploading is a perfectly reasonable choice.

Two ways an online tool can handle your file

From the outside, every online PDF tool looks the same: you pick a file, click a button, and a new file downloads. Underneath there are two very different designs.

Server-side tools send your file over the internet to a computer the site controls. That computer merges, compresses or converts it, and your browser downloads the result. For a while, however short, a copy of your document exists on a machine you don't own.

Browser-based tools send the page and its code to you instead. Modern browsers let a web page read a file you've picked and build a new one on your own machine, with no network involved. The processing happens on your laptop or phone, the same way it would in a desktop app.

Neither design is dishonest in itself. Plenty of reputable services process files on their servers and handle them carefully. The point is that you should know which one you're dealing with before you drop in something sensitive.

Which files deserve the check

Merging two restaurant menus doesn't need a security review. But look at what people actually run through these tools: signed contracts, bank statements, payslips, tax forms, scans of passports and ID cards, medical letters, photos of children. Those are the files where a copy on somebody else's server is a real cost, not a theoretical one.

A simple rule: if you wouldn't email the file to a stranger, check the tool before you give it the file.

The two-minute check: watch the Network tab

Every desktop browser has developer tools built in, and one panel in them, the Network tab, lists every request the page makes. An upload can't hide from it. You don't need to understand code to read it; you're only looking for one kind of line.

1. Open the tool's page as normal.
2. Open the developer tools: press F12, or Ctrl+Shift+I on Windows and Linux, Cmd+Option+I on a Mac. In Firefox, Ctrl+Shift+E opens the Network panel directly.
3. Click the Network tab.
4. Tick Preserve log (Firefox calls it Persist Logs, under the gear icon), so the list isn't wiped if the page reloads after processing.
5. Clear the list with the clear button (a circle with a line through it).
6. Now use the tool the way you normally would, but with a test file rather than the real one. Pick it, press the button, wait for the result.
7. Look at what appeared in the list.

What an upload looks like

Turn on the Method column if it isn't showing (right-click any column header). An upload is almost always a POST or PUT request, sent right after you picked the file or pressed the button. Click it and open the Payload tab (Request in Firefox). If you see your file's name, or a form field marked (binary), that's your file leaving your computer.

Other signs point the same way: a request that takes several seconds to finish, a domain with words like upload, api or storage in it, or a progress bar on the page that fills up before any "processing" starts. The progress bar is often the giveaway. It's measuring the upload.

If the list is long, use the Fetch/XHR filter first, since that's where most uploads show up. Then go back to All to be sure you haven't missed one sent another way.

What a browser-only tool looks like

You'll see either nothing new at all, or only GET requests for files ending in .js. Those are the tool downloading code to you, not sending anything from you. A GET request for a script has no payload of yours in it.

Here's a concrete example from this site. Open the PDF merge tool, clear the Network list, add two PDFs and merge them. The first time, one request appears: a GET to cdn.jsdelivr.net for pdf-lib.min.js, the open-source library that does the merging. Merge again and nothing new appears at all, because the library is already loaded. At no point is there a POST.

A rough extra signal: time a big file

Try a large test file, say 50 MB. On a typical home connection, uploading that takes a noticeable while, often much longer than the download. If a tool finishes a 50 MB file in a second or two on an ordinary connection, the work probably happened locally. Treat this as a hint, not proof. The Network tab is the real test.

A check with no developer tools: go offline

On a phone, or if the developer tools feel like too much, there's a blunter test.

1. Open the tool and run it once with a harmless file.
2. Turn off Wi-Fi (or switch on airplane mode).
3. Run it again with another file.

If it still works, the processing is happening on your device. If you get a network error, or it spins forever, it needed a server.

Step 1 matters more than it looks. Browser-based tools, ours included, often download their processing library the first time you press the button, not when the page opens. Go offline before that first run and a perfectly local tool will fail, which would give you the wrong answer.

One limit: in theory a page could wait until you're back online and upload then. It's unusual, but it's why the Network tab, with Preserve log ticked, is the stronger check.

What "files are deleted after one hour" actually tells you

This line is on a lot of tool sites, and it's often read as reassurance. Read it literally instead. It tells you three things:

• The file is uploaded. You can't delete something you never had.
• It's kept for up to an hour, sometimes longer, on the site's systems.
• The deletion is a promise. You have no way to confirm it happened.

None of that makes the site dishonest. Many of them do delete on time. But a promise is only as good as the questions behind it, and a decent privacy policy answers them: which country the servers are in, whether another company processes the files, whether backups or logs keep copies, and whether uploaded content is ever used for anything else.

Some wording worth recognising:

Notice the fourth row. A browser-only claim is the one kind of privacy promise you don't have to trust, because you can check it yourself. If a site says it, test it. If the test disagrees with the policy, believe the test.

When uploading is the right call

Browsers are capable, but some jobs still belong on a server. Reading text out of a scanned page (OCR) and converting a PDF into an editable Word file with its layout intact are the common ones. Our tools do neither. The same goes for a 300-page scan on an old phone that would struggle to process it.

When you do need one of those, a few habits lower the risk:

• Pick a service whose privacy policy you've actually read, using the table above.
• Send only the pages you need. Split them out first, locally, with a tool like the PDF splitter.
• Strip the document's metadata before it goes anywhere (next section).
• Delete the file from the service yourself if it offers a delete button, rather than waiting for the timer.

The file can give things away, whoever processes it

Even a perfectly private tool can't help with what's already inside the file. A PDF typically carries a hidden set of properties: a title, an author (often filled in automatically from the name on your computer account), the program that made it, and the date it was created and last changed. Many PDFs also keep a second copy of these details in an XMP block that ordinary viewers never show. When you email that PDF or upload it anywhere, all of that goes with it.

You can see exactly what a file carries with the PDF metadata viewer, which reads the file in your browser and can clear the fields, both dates and the hidden XMP copy before you send it on.

Photos have the same problem in a different form. Phone cameras store EXIF data in each image, which can include the date, the phone model and, if location is switched on, the GPS coordinates where the photo was taken. When our image compressor re-saves a photo, the browser redraws it from pixels, so the new file comes out without the original EXIF block. That's a side effect of how browsers save images, but it's a useful one.

Before you upload anything: a short checklist

1. How sensitive is it? If you wouldn't email it to a stranger, keep going down this list.
2. Test the tool with a dummy file and watch the Network tab for a POST or PUT.
3. If it uploads, read the privacy policy: how long files are kept, where, and whether they're used for anything else.
4. Send the minimum: only the pages you need, with metadata removed.
5. If a site says "local" or "no upload", make it prove it. The check takes two minutes.

How our tools handle your file

Since we've just told you to test every site, here's exactly what you'll find if you test Toolipi.

Every PDF and image tool here runs in your browser. None of them sends your file, or anything read from it, to our server. In the Network tab you'll see the page itself, its stylesheet, fonts and scripts, and on the PDF tools a library from cdn.jsdelivr.net (pdf-lib, pdf.js or jsPDF) the first time you run the tool. Those libraries are pinned to an exact version and checked against a fingerprint, so if the copy served ever changed, your browser would refuse to run it.

There is one kind of POST you might see, and we'd rather tell you now than have you find it. If a tool crashes, the page sends us a short error report to /log/client-error so we know it's broken. The report says which tool failed, the error message and where in our code it happened. When an image tool can't read a file, it also includes the file's type and size (something like "image/png, 4,194,304 bytes"). It never includes the file itself, its name or anything read from it. If nothing breaks, no report is sent, and you can open the request in the Network tab and read every field.