No-Upload Alternatives to Online File Tools

Every "alternative" list ranks the wrong thing

Search for an alternative to any of the big online file tools and you get the same page a dozen times over: a feature grid, a price column, a verdict. Features and prices are easy to list, which is why everybody lists them, and they are also the things that will be different next quarter.

There is one difference between these tools that does not move, and that you can settle for yourself in under a minute: does your file leave your device?

Either the bytes of your contract are transmitted to a company's server, processed there and sent back, or they are read by code running inside the page you already have open and go nowhere at all. Nearly everything else people compare — the watermark, the daily cap, the sign-up wall, the file size limit — follows from that one decision rather than causing it.

So this post is about that axis and nothing else. What the large tools say about it on their own pages, how to test any tool rather than trusting what it says, what insisting on local actually costs you, and which jobs cannot be done that way at all.

One disclosure first, because it changes how you should read the rest: BitsSolved runs a set of free browser tools, so we are one of the answers to this question. That is exactly why the checking method below is written so that it works on us too.

What the big ones say, in their own words

None of this is hidden and none of it is a scandal. Every company below publishes what happens to your file. Almost nobody reads it, because it lives in a privacy notice rather than next to the Upload button.

Each of those is quoted from the company's own live documentation: iLovePDF's privacy policy and security page, Smallpdf's privacy notice, the FAQ on tinypng.com, Adobe's FAQ for Acrobat online services, and the notes under PDF24's merge tool.

The exact wording is worth reading, because the precision is the point.

iLovePDF commits to a number: "ILOVEPDF will delete the files of your Content ... within TWO (2) HOURS of being processed on ILOVEPDF's servers." Its security page repeats it and adds a manual escape hatch — files are "automatically and permanently deleted within two hours", and users get "the option to manually delete files from the download screen".

Smallpdf names its infrastructure, which is unusually open: it uses Hetzner "to process files uploaded by the user", temporarily, on servers in the European Union. Then the retention splits in two. With an account, "we delete User Files within one hour unless you save them to your file storage". Without one, the sentence has no number in it: Smallpdf "will generally aim to delete User Files within a reasonable period of time after the last time they were opened", and "this retention period is extended every time you reopen the respective User File."

TinyPNG answers the question "Is the privacy of my images ensured?" with "only you have access to the images you upload. We retain them for a maximum of 48 hours, after which they are permanently deleted." The same FAQ sets the free ceiling: 20 images at once, 5 MB each, and three free format conversions.

Adobe is the bluntest of the five, in one sentence: "Acrobat online services upload your files to Adobe cloud storage." If you do not sign in, "Adobe will delete the file from the server within a short time period".

PDF24 explains the reason rather than the policy, and it is the most useful sentence on this page: "PDF files are merged in the cloud on our servers so that this PDF merger does not take up the resources of your system."

Two things to notice. The first is that every one of those statements is a retention period, and a retention period is a fact about a file that arrived somewhere. You can read them all and conclude the risk is small, because for most documents it genuinely is. What you cannot do is read them and conclude the file stayed with you.

The second is that the number is sometimes not a number. "A reasonable period of time", extended each time the file is reopened, is a real policy that a careful company wrote carefully. It is also not something you can put in a sentence to your client about where their contract went.

"In your browser" does not mean "on your device"

Here is the phrase that costs people the most, and TinyPNG's own site is the clearest illustration of it, with no bad faith involved anywhere.

The line tinypng.com uses to describe its own Image Compressor & Converter reads "Compress and convert AVIF, JXL, WebP, PNG and JPG instantly in your browser". Its FAQ, on the same site, says your images are uploaded and kept for up to 48 hours. Both are true, of different things. The interface is in your browser. The work is not.

"In your browser" is the industry's standard way of saying "there is nothing to install". It is a claim about convenience, not about data. Sort the vocabulary once and you stop being caught by it:

• Phrases about the interface: in your browser, online, instant, web-based, no software needed, works on any device.
• Phrases about the data: never uploaded, never leaves your device, processed locally, client-side, offline-capable.
• Phrases that settle nothing on their own: secure, private, encrypted, GDPR-compliant, bank-grade.

That third group needs one example. iLovePDF's security page says it uses "end-to-end encryption to ensure the highest level of security for your data from the moment you upload it until it's processed and delivered back to you." Read slowly, that is an accurate and honest description of a round trip. Encryption in transit protects a file that is travelling. A file that is travelling is a file that is going somewhere.

Check it yourself, in under a minute

Do not take anyone's word for this, including ours. Three tests, in increasing order of certainty.

1. The payload test. This one is conclusive. Open the tool's page and open DevTools — F12 on Windows, Command-Option-I on a Mac — then go to the Network panel. Clear the log, then do the thing — drop the file, press the button. Now look down the list of requests for any POST or PUT. Select it and open the Payload tab, which Chrome's own network reference describes as the place to "view the request's payload, that is, its query string parameters and form data". If your file's bytes are in there, your file was transmitted. If the only requests after you drop the file are for scripts, fonts and analytics, it was not.

2. The offline test. Fast, with one caveat. Load the page fully, then set the Network throttling drop-down to Offline — Chrome documents it under "Emulate offline" — and run the tool. If it still works with no network at all, the work is unambiguously happening on your machine.

The caveat matters: a genuinely local tool can still fail offline, because many of them fetch a WebAssembly module or a worker script on demand the first time you use a feature. So a failure here is a prompt to go back to test one, not a verdict. A success, though, is proof.

3. The download test. No DevTools needed. When the result appears, look at where the download comes from — right-click the download button and copy the link address, or open your browser's downloads list. A result that was built inside the page arrives as a blob: URL, created from bytes that already exist in the tab. A result that arrives from https://their-server/download/... was built on a server, which means the input went there.

Why any of this works is worth one paragraph, because it is the thing most people have backwards. Choosing a file in a web page does not send it anywhere. MDN's guide to using files from web applications describes what actually happens: the page receives File objects representing what you selected, and can read them locally. Transmitting them is separate code that the page has to deliberately run. Upload is a choice the tool makes, not a consequence of the file being chosen.

What you will see if you run those tests here. Our tool pages load their own scripts and styles, and a Google Analytics tag, so you will see requests to googletagmanager.com — you can turn that off permanently for your browser by visiting any page once with ?noga=1 on the end. You will see one call to /v1/auth/me, which asks whether you are signed in. Then you drop a file, and nothing new appears in the list. The download is a blob: URL. The run counter that enforces our free limits is in your browser's own storage under the key bs_tool_usage — five runs per tool per day, fifty if you sign in with an email — which is also the honest reason those limits are soft rather than strict: there is no file on our side to count.

What runs locally here, and what does not

There are 132 tools on this site. 114 of them do their work entirely in the page. The other 18 call our server, and the split is not arbitrary: none of the server-backed ones takes a file. They take a hostname or a URL, because the answer they need is out on the internet rather than in your folder — the DNS, SSL, HTTP header, redirect, robots, sitemap, WHOIS and website health checkers. Our privacy page draws the same line in the same words.

Everything that touches a document or a picture stays put:

• PDFs. Merge PDF and Split PDF rearrange pages with pdf-lib in the tab. PDF Compressor re-renders and rebuilds the file there too. PDF to JPG renders pages with pdf.js, the same engine Firefox uses to show you a PDF in the first place.
• Images. Image Compressor, Compress Image to Target Size, Image Resizer, WebP Converter and Photo Cropper all run on the canvas engine your browser already ships.
• The ones where it matters most. JWT Decoder, JSON Formatter, Password Generator and Invoice Generator.

That last group deserves a sentence of its own, because it is the category people are least careful with. A production JWT pasted into a form on a site you do not control is a live credential handed to whoever runs that site, valid until it expires. The same goes for a JSON payload with customer records in it, and for an invoice carrying your client's name and your bank details. These are not files anyone thinks of as sensitive, and they are more sensitive than most PDFs.

What browser-local costs you

Every page arguing for local tools skips this part. Here it is, because you will hit all of it within a month.

No OCR. Nothing that runs in a tab here will read the text off a scanned page. PDF24 lists PDF OCR among its tools and iLovePDF has its own; if you need searchable text out of a photographed document, your options are to upload or to install software. There is no third answer.

No real conversion to Word or Excel. Reconstructing an editable document from a PDF is a heavy job, and the services that do it well — iLovePDF and Smallpdf both offer PDF to Word — do it on their own machines.

No unlocking a PDF whose password you do not have, and no e-signature with an audit trail behind it, which by definition needs a third party to witness and store something.

Our PDF compressor turns text into pixels. It re-renders each page as an image to get the size down, and its own FAQ says so plainly: "pages are re-rendered as images to achieve strong compression, so text becomes part of the page image." For a scan heading into a portal with a 5 MB cap that is exactly right. For a contract that has to stay searchable, a server-side compressor that preserves the text layer is the better tool, and you should use it.

Your device does the work, and you will notice. PDF24 said it out loud and they were not wrong: the cloud exists so the job "does not take up the resources of your system". A 300-page scan on a five-year-old laptop will take a while and warm it up. What you get in exchange is that the ceiling is your own hardware rather than someone's free tier — no 20-file batch limit, no 5 MB per image, no queue. Our merge tool's answer to "is there a limit" is "no fixed limit", bounded only by browser memory, and that is a different kind of promise from a quota.

Nothing waits for you on another device. A server tool hands you a link you can open on your phone. A local tool hands you a file in your Downloads folder on the machine you used.

No API, no batch pipeline. If the job is "every PDF that lands in this folder, every day", you want a server or a desktop application, not a browser tab.

A rule for deciding

Three cases, and only the middle one is hard.

Routine shaping of a file you already have — resize, compress, merge, split, rotate, crop, convert a format. There is no reason on earth for this to involve a round trip to a data centre in another country. Use something local and stop thinking about it.

The file is one you would not email to a stranger. A signed contract, a bank statement, a scan of an ID, a payroll sheet, a client's unreleased work, a config file with a token in it. Local, or installed software, and if neither can do the job, the right question is whether the job is worth doing this way at all. The test is literally that: if you would not attach it to an email to someone you have never met, do not drop it into their form.

The job genuinely needs a server — OCR, a real conversion to Word, a witnessed signature, thousands of files at once. Then upload, but do it deliberately. Read the retention sentence once before you start. Prefer the vendor's desktop application if there is one, since the same companies sell exactly that: iLovePDF's desktop app is pitched on "process files with maximum security and privacy locally on your computer", which is a fair summary of this entire article written by a company that uploads for a living. Delete manually from the download screen where that is offered. And do not sign in unless you want the file kept: on Smallpdf and on Adobe's online tools, signing in is the thing that turns a temporary file into a stored one.

Others on the right side of the line

We are not the only answer, and for some jobs we are not the best one. A comparison that only ever arrives at the author's own product is not a comparison.

Squoosh, from Google, states it on its own front page: "Images never leave your device since Squoosh does all the work locally." For one image at a time, with real codec controls and a side-by-side view of what each setting costs, it is the best thing there is. Reach for it when you are choosing an encoder; reach for a batch tool when you have forty product photos and already know the setting.

Stirling is the serious answer for a team. Its own page makes the argument for verifiability rather than trust: the editor "runs on your machine, and the source is public so you can verify that instead of trusting it". Self-hosted, with OCR and batch processing, and the file never leaves the building.

The vendors' own desktop apps, as above. The companies that process your files on their servers will all happily sell you the version that does not.

Our tools are for the ordinary middle of this: open a page, do one thing to one file, close the tab, and have the file never go anywhere. That is a narrower promise than any of the above, and it covers most of what anyone actually needs in a week.

Start here

1. Pick the online tool you used most recently with a file that mattered. Open it again.
2. Run the payload test. Thirty seconds, and you will never have to wonder about that tool again.
3. If it uploaded, look back at what you sent. Not to panic about it — the retention policies above are mostly sober and short — but because you now know the answer for the next file instead of guessing.
4. Move the routine jobs somewhere local. Ours, Squoosh, or an app on your machine. Resize, compress, merge and convert have no business being a network request.
5. For the jobs that genuinely need a server, keep using one on purpose, having read the one sentence that says how long the file stays.

While you are at it, the companion to this for images is resize, compress, convert, in that order — the order saves more bytes than any tool choice does, and it is the same three local tools either way.

And if you are building a product where customers hand you their files, where the processing happens is an architecture decision, not a detail of the implementation. It sets what you are liable for, what you have to disclose, and what you have to pay to run. Deciding it on purpose at the start is cheap; discovering it later is not. That is ordinary scoping work for us under web application development, and it is worth half an hour before the first line is written.