Testing composer image optimization

Continuing the discussion from Optional image optimization before upload:

This feature is now available for testing here on Meta. Uploading an image here will trigger a resize/encode in the user browser before it’s sent to the server.

Please give it a try, here in this topic or in your own community by enabling the “composer media optimization image enabled” site setting. We are leaving it off by default while we test it.

To illustrate the differences, here is a before/after:

The picture is freshly taken from my phone and went from 3.7Mb to 416Kb using our default settings.

The goal of this feature is what @sam described here:

Discourse ships with a 4MB limit for user uploads out of the box. Now I can drag and drop a 58MB JPEG:

And it uploads just fine.


Here’s a 57MB photo of some trees I took 10 years ago, dragged into the composer

That was pretty quick! :rocket:


Nice work!

One minor point about the loading percentage metre. When uploading this 6.1MB HEIC image I found it progressed to 100% relatively quickly, then stayed there for about 50 seconds before completing. That could cause some confusion / cancelling.

Video of the issue: Loom | Free Screen & Video Recording Software


This is awesome. A quick question, maybe an obvious one - would it be possible to only have it enabled on images higher than the site limit? Thus, images up to the limit are not processed, but if someone tries to go over it will seemingly downscale it?


This is something what I waiting for long time :heart_eyes: Thank you Falco.

I have a question. Is it optimize older images with rebake posts or only the new uploads? Thanks again :slightly_smiling_face:


You did not test this new feature as it doesn’t work on ingested HEIF images. I wanted to work with HEIF but browser support for decoding that is inexistent HEIF/ISO Base Media File Format | Can I use... Support tables for HTML5, CSS3, etc. So you tested the server side HEIF conversion that we have working for quite some time already.

I could make it work by shipping a WebAssembly decoder, but those images are so rare that I didn’t find it necessary because we already have the server side conversation that @pmusaraj worked on.

As of now this feature can ingest JPG, PNG and GIF. I can easily add support for AVIF/JPEGXL/TIFF and will do so soon.

Yes! Tweak composer media optimization image kilobytes optimization threshold to the desired value.

No it won’t. This work happens in the user browser, just in time before the upload. Rebake is a server side process, so they are quite different.


(A 28 MB photo I took from my city centre during the first confinement in 2020)

I tested the upload with various connection speeds, from 1 Gbs to 1Mbs. Worked well, except for the 1 Mbs bandwidth. The uploading behavior with the latter being a bit strange.

Stuck to 0% for a long time, then a quickly increasing percentage (faster that a 1 Mbs connection would upload), then stuck a 100% for a long time before showing this message:


Note that my picture original format is jpg, not png… :thinking:

[Uploading: 20200328_141218.jpg...]() remained in the post, instead of showing the picture.


Two issues:

  1. if we cancel the message and discard the draft while we were uploading a picture, and then we want to post a new reply, the loading progression is still shown on the composer :

    We have to reload the page in order to make this go away.

  1. It’s kinda confusing for the user that the site allows to send and display a 50 MB picture, but when I try to send a 21600×21600 108 MB picture (from here), I get this message:

    The confusion here is the > 4 MB forbidden but 50+MB pictures allowed anyway.
    What’s the real reason for which I can’t upload this picture?


Pretty cool photo! From 28MB to 113KB is a pretty good ratio!

So this new feature only changes the ‘pre-upload’ phase. We intercept the file you try to upload, apply transformations on it and then swap the new smaller file and resume the old upload process.

It stays at 0% and uses “Processing…” in the pre-upload phase, so that is expected. I will try to also swap the “Uploading…” string at the bottom too.

4MB is still forbidden, the trick is that we optimize the image so it’s >4MB when possible, so it can survive the file size limitation.

I tried a few images from that site, but they all use PNG opacity so I can’t safely convert to JPG and the optimizer bails out.

I tested a 60MB PNG now, and the optimizer can deal with it, but uses over 4GB RAM while doing so to end up with a 360KB JPG.

What device, browser and OS version you were using on this test?


I added a new ‘Processing Upload’ composer status message so you know exactly what is happening now.

This feature is safe to be tested now, please let me know how it goes in your community!


Trying with a 1.6MB photo I took on my iPhone:

Wow, 300k and very high quality.




Hello Falco,

I started use the composer image optimization. I notice if i want to upload more photos then it will activate the reply button after the first image uploaded and only deactivate when the next image optimization finish. If click the reply button in this time then the other image uploads stuck and will compose only the text (processing). I cannot repro here because on Meta change the button quickly but on my site it hang most of the time ~10sec or more between uploads. I use the default settings and 3x ~3-4MB images

I tried it with Huawei P20 Pro Android 10 (Chrome 91.0. 4472.120) Webapp.

As you see on the video after the uploads (Feltöltés) the reply button activate. Each image ~2.3MB.

Is that possible to disable Reply button all the time while images upload?

I am confused with this settings. Is “kilobytes” is correct?

Screenshot 2021-07-16 at 10.41.51

Thank you for the answer! :slight_smile:


Thanks for the report! There was a bug when calculating the disabled status of the button:

Yes Kilobyte - Wikipedia. It defaults to half a megabyte, but you can tweak as you need. I’d recommend going as low as ~300kb if you want to save the most space.


Thanks for the fix. :slightly_smiling_face:

I see. I just thought that this is a misspelling bytes to kilobytes. Because I put 524288kb to the converter and it says 512mb. That was I confused it. But yeah now I understand :slightly_smiling_face: Thanks


Ohhhhh I see it now. My bad!



Thanks for the fix :slight_smile: Now it is working great!

I have a question about mobile uploads. When i upload image from mobile it will not resize the image to the target px width. I think only the quality changes. If i try it on Desktop pc the resize working. Am I missed something? Thanks :slight_smile:


We try to resize on both mobile and desktop, but the resize operation may fail if your device hardware is too weak. When that’s the case we skip it.