Client-side implementation has a lot of issues. What I think would work better is a server-side implementation. Something like a much larger limit - perhaps 20 MB. On upload, server code compresses on the fly down to the desired size (e.g., 2 MB) and only stores the compressed image. This is relatively easy to do in most languages. I actually created a small web site to do this for use Somewhere Else but obviously can't integrate it into that system, while I have hopes that someday I will be able to do that here (after learning Ruby, etc.). There are additional problems - a lot of casual users know how to take pictures with their phones and share them via email/WhatsApp/text/etc. but have no clue how to upload directly to a web site, so I have some ideas on fixing that as well by allowing directed emails - e.g., send to postid-image@codidact.com and it automagically is compressed and loaded into the post.

manassehkatz‭ Well, I just assumed the purpose of having that low limit was to reduce server load, by requiring far less data transfer. As long as the server can handle such higher limits, and there's nothing to actually save by doing it client-side, then it's a possibility to do it server-side. Although, even if the server is fine with receiving such amounts of data, the client might not have such a good bandwidth. Not too many years ago, I lived with horrible data upload speeds, and I assume lots of people still do.

a lot of casual users know how to take pictures with their phones and share them via email/WhatsApp/text/etc. but have no clue how to upload directly to a web site, so I have some ideas on fixing that as well by allowing directed emails - e.g., send to postid-image@codidact.com and it automagically is compressed and loaded into the post.*

I honestly have no idea how that makes sense. Maybe I'm too used to computers. I just don't find that to be realistic. I'm aware certain people struggle with computers, and might already know how to send a file over e-mail, for instance, but under no circumstance does that seem simpler than tapping the image upload button in the editor. It's far more complicated.

The issue isn't so much transfer time (it is a one-time thing if compression is done immediately after transfer) as it is storage space. Storage space is a lot cheaper than it used to be, but some limit is necessary for both economic and practical reasons. An awful lot of people take pictures on their phones and have no idea how to do anything with the pictures except what the phone makes it trivially easy to do. Typically that means: email, text, WhatsApp, etc. where the phone (Android or iOS) "knows" certain things to do and can feed a saved picture into another application. But the image upload button inside a web page works differently and for a lot of people figuring out how to browse/find their pictures is not so easy.

I agree on server-side implementation. But this can also mean client-browser-side (before upload) Andreas lost his angel wings mentioned this in the other comment. Generally it should not mean user-side.

A user should not be loaded with server-side concerns. If there is need for restrictions, make them transparent for the user. Meaning: don't make them fit your concerns. That is just off-loading problems to their shoulders. Accept their input and apply your concerns on it. That is ease-of-use and the right way of handling those restrictions.

Also just stating "max 2MB" without some nice buttons offering "Auto-Resize" and "Auto-Compress" or "Auto-Upload-to-Sharing-Service" is very 1990.

The other data-transfer issue is serving the web page. We need to support a user on a phone with a so-so connection. If the page takes forever to load, that's bad - and all that extra resolution won't even be useful when it does finally load.

On the upload side, we should resize images that exceed our limit (whatever that limit is) instead of making the user do it. If we allow storing high-res pictures, we should scale down if the user agent is a small screen. Either part of this would be an improvement; both would be a big win for users.

Monica Cellio‭ Loading images should be deferred to after the page itself has loaded, such that they don't hold up loading in the page itself, and interacting with it. Additionally, you can load in lower quality versions until the full quality one has been downloaded.