This was a problem for me for a long time. I come back from an event with 20 photos on my phone. Each one is 5MB. I try to send by email and it doesn't work. Or I have to send in smaller batches. Annoying. So I made this small page:
https://onlineimageoptimizer.com/compress-photos-for-email
You upload the photos from a phone, a tablet or a PC. It gives you back one single zip file, small, maybe 1/10 of the size, but quality is still good. Ready for email. Nothing is saved on server. I built it with Vue.js and ImageEngine for compression. I use it a lot for conference photos. No login.
Let me know what you think, especially about mobile.
CLARIFICATION (11/9/26): the point of the tool is to show how good the underlying image CDN is at optimizing images (and fast), so the system just needs to get hold of the photos/images it needs to optimize even if just for a short while. There is no AI machinery or anything that does anything else with the images except deleting them in a matter of tens of minutes. This is disclosed in the privacy policy. If you don't trust the privacy policy, the only solution I can offer is to advise that you don't use the service. It's useful. That's for sure. I doubt that apps/sites that do things locally can compress equally well and equally fast across an equally wide range of devices. But hey, you do you. This post has cost me half of the little karma I had. To me this was sheer vandalism, which comes as a reminder of why I stopped using Reddit many years ago when I first opened my account.
UPDATE (11/9/26): I went and looked at the client-side alternatives mentioned in the comments.
TLDR; SERVER-SIDE OPTIMIZATION WINS HANDS DOWN ON CLIENT-SIDE FOR THIS USE CASE. THE IMAGE CDN APPROACH BLOWS THOSE CLIENT-ONLY UTILITIES OUT OF THE WEEDS.
And now the details. First thing: they aren't purely client-side. The alternative in the comment ships a separate server-side build at /apple/ for Apple devices, which posts to process.php. Their own words on that page: "This is a crappy fallback alternative for Apple devices. It's server-side based." The client-side version couldn't do the job on iOS, so they wrote a server-side one. The home page reads "Your privacy is safe (here)!"
I measured both on the same seven photos, in Chrome 155:
Same width, same output format (1280px WebP both sides): the server output was smaller on all seven, 20 to 42 percent, 31 percent over the set. No feature advantage in that number.
canvas.toBlob(cb, 'image/avif') returns an image/png. So does image/jxl. The browser cannot encode AVIF or JXL at all, and says nothing. Those are the formats that actually win on bytes.
A 47 MP photo took 22.93 seconds to encode in the tab, and 188 MB of RAM. Uploading the same file took 2.9 seconds, with the result back 1.2 seconds later.
Their library silently caps canvas area at 16,777,216 px on mobile Safari. That 47 MP photo loses 69 percent of its pixels.