Well, I wouldn't use such a website anyway (especially a document converter -- that is better done using a real application), regardless of where the processing was done, unless I was very certain that the website was trustworthy. For one thing, even if the website purports to not move my data to their servers, how do I know they're being truthful without going to extremes such as sniffing traffic?

There have been plenty of sites that have lied about such things.

You can swap out my examples for anything really.

The point is the more work the server does, the more data you have to send them to do that work.

As far as trusting it's client-side only, opening the network tab in devtools would suffice.

If you think they broke the sandbox (Google would pay millions for that!), yes sniffing would be the next step.

At least you have a sandbox on web, you usually don't have that for native apps.

But that's all better than willingly sending data to another entity's server and trusting them to not abuse/leak it.

With a couple of necessary exceptions, I don't use websites to store or process personal data, so that's not really the use case I have in mind.

What I have for native applications that I don't for the web is the ability to firewall off the native applications.

> What I have for native applications that I don't for the web is the ability to firewall off the native applications.

There you're placing trust on the firewall's sandbox. Are you sure the application can't communicate with the outside at all? DNS exfliltration for example?

A firewall is not a sandbox, but yes, I am sure that the applications can't communicate with the outside at all. My logs would show if they were. Any and all packets that originate from them are dropped, including DNS lookups and the like.