Your file is re-encoded on upload, and you can plan for it

You are not the last encoder

You spend an hour on an edit, export a careful 2400-pixel JPEG at quality 88, upload it, and it arrives soft, slightly grey and about 180 KB. Nothing went wrong in your export. The platform re-encoded it.

Essentially every consumer platform (social networks, marketplaces, messaging apps, forums, most content management systems) resizes and re-compresses on upload. They do it for bandwidth, for storage, and to normalise the wildly varying files their users send. Your file is an input to their pipeline, not the thing that gets served.

Once you accept that, the job changes: give their encoder the best possible input, and lose the least in their pass.

The three things their pipeline does

It resizes to a fixed width. Each platform has its own set of widths, and if your file does not match one, it is resampled to the nearest, usually without gamma correction and always without output sharpening tuned to that size. This is the largest single cause of the softness.

It re-compresses. Your quality-88 file is decoded and re-encoded, often more aggressively and often at 4:2:0 chroma subsampling regardless of what you chose. Everything the JPEG lesson says about generation loss applies, and you get one whole generation whether or not you edited anything.

It strips metadata. Usually including the ICC profile. A file that was not converted to sRGB before upload is then read as sRGB, and comes out flat in exactly the way the export lesson describes. This is why wide-gamut exports look dull on social and fine in your editor.

Some platforms also re-encode to their own format. Serving WebP or AVIF to browsers that accept them is now standard, so the file a reader receives may not even be the format you uploaded.

Matching their width is the whole trick

If you upload at a width the platform already uses, its resize step becomes a no-op or close to it, and your sharpening survives.

The widths move, so treat any list as something to verify rather than memorise. The method for verifying is fixed and takes five minutes: upload a test image, view the post in a desktop browser, right-click the displayed image and open it in a new tab, and read the dimensions and file size of what you were actually served. Do that once per platform you work with, write it down, and redo it when your results change.

What you will generally find: feed images on the large social networks are served somewhere between 1080 and 1440 pixels on the long edge; marketplaces are larger because of zoom, commonly 1600 to 3000; messaging apps are far smaller and far more aggressive than anything else, often under 1600 pixels and heavily compressed.

Giving their encoder a good input

Six things, in order of how much they help:

1. Convert to sRGB and embed the profile. Costs nothing, and prevents the most visible failure.
2. Upload at the platform’s own width where you can determine it.
3. Sharpen a little less than you would for final delivery. Their re-encode will exaggerate halos, and a file sharpened for print arrives crunchy.
4. Give it a high-quality JPEG or a PNG, not a file you already squeezed to 90 KB. Compression artefacts in your input become the input to their compression, and the two stack. This is counter-intuitive: you are uploading a larger file to get a smaller, better one back.
5. Avoid fine dithered gradients and heavy grain, which are what their encoder spends its budget on and loses first.
6. Send as a document, not as a photo, where the platform offers the distinction and the recipient needs the real file. Most messaging apps have this option, and it bypasses the whole pipeline.

The cases where none of this is enough

Some things cannot be pre-empted, and it is better to know than to keep fighting.

Repeated re-uploads. A picture downloaded from one platform and posted to another has been re-encoded twice, and the third generation is visibly degraded. Always upload from your own master.

Screenshots of your work. Every screenshot is a fresh capture at somebody else’s screen resolution with your metadata gone and no way to object.

Platform colour handling on phone apps. Some apps do not colour-manage at all on some devices, and a P3 display will show a saturated version of an sRGB file that you cannot correct for without wrecking it everywhere else. Deliver correct sRGB and let it be their bug.

Automatic enhancement. A few platforms and several phone gallery apps apply their own contrast or saturation adjustment on upload or display. There is no setting you can send that turns it off.

Today: upload one image you edited carefully, download the version the platform serves back, and open both at 100 per cent. The difference is the pipeline you are working through, and knowing its size changes how much effort the last five per cent of your edit deserves.