{"course":{"slug":"image-editing","title":"Editing an Image","url":"https://addaly.com/learn/image-editing","level":"beginner","track":"create"},"lesson":{"slug":"what-the-platform-does-to-your-file","title":"Your file is re-encoded on upload, and you can plan for it","url":"https://addaly.com/learn/image-editing/what-the-platform-does-to-your-file","position":77,"of":78,"minutes":9,"answer":"Platforms resize, re-compress and strip the profile from every upload, so convert to sRGB, match the width they actually serve, sharpen slightly less than for final delivery.","keyIdea":"Platforms resize, re-compress and strip the profile from every upload, so convert to sRGB, match the width they actually serve, sharpen slightly less than for final delivery, and give their encoder a high-quality input rather than one you already compressed."},"body":{"format":"markdown","text":"## You are not the last encoder\n\nYou 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.\n\nEssentially 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.\n\nOnce you accept that, the job changes: give their encoder the best possible input, and lose the least in their pass.\n\n## The three things their pipeline does\n\n**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.\n\n**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.\n\n**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.\n\nSome 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.\n\n## Matching their width is the whole trick\n\nIf you upload at a width the platform already uses, its resize step becomes a no-op or close to it, and your sharpening survives.\n\nThe 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.\n\nWhat 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.\n\n## Giving their encoder a good input\n\nSix things, in order of how much they help:\n\n1. **Convert to sRGB and embed the profile.** Costs nothing, and prevents the most visible failure.\n2. **Upload at the platform's own width** where you can determine it.\n3. **Sharpen a little less than you would for final delivery.** Their re-encode will exaggerate halos, and a file sharpened for print arrives crunchy.\n4. **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.\n5. **Avoid fine dithered gradients and heavy grain**, which are what their encoder spends its budget on and loses first.\n6. **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.\n\n## The cases where none of this is enough\n\nSome things cannot be pre-empted, and it is better to know than to keep fighting.\n\n**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.\n\n**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.\n\n**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.\n\n**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.\n\nToday: 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."},"check":{"question":"An editor compresses images hard before uploading to a social platform, reasoning that a smaller input means less for the platform to degrade. The posted images look worse than a colleague's, who uploads large high-quality files. Why?","options":[{"text":"Large uploads are given priority in the platform's encoding queue and receive a higher quality setting.","correct":false,"tempting":"Invents a policy; the pipeline applies the same settings regardless of input size."},{"text":"Their encoder re-compresses what it receives, so your artefacts are encoded again and the two losses stack.","correct":true},{"text":"Small files are upscaled to the platform's fixed width, and upscaling is what introduces the visible damage.","correct":false,"tempting":"Identifies a real step but the wrong one: the colleague's files are downscaled to the same width and still come out better."},{"text":"Heavier compression removes the ICC profile, so the pre-compressed files are interpreted in the wrong colour space.","correct":false,"tempting":"Ties profile loss to the quality setting, when the platform strips metadata from every upload regardless."}]},"prev":{"slug":"serving-the-right-file","title":"One picture, six files, and letting the browser choose","url":"https://addaly.com/learn/image-editing/serving-the-right-file"},"next":{"slug":"the-whole-job","title":"One bottle, one window, twelve minutes","url":"https://addaly.com/learn/image-editing/the-whole-job"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'Your file is re-encoded on upload, and you can plan for it', in Editing an Image. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/image-editing/what-the-platform-does-to-your-file (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"Your file is re-encoded on upload, and you can plan for it","courseTitle":"Editing an Image","module":{"index":8,"slug":"out-of-the-editor","title":"Out of the editor: size, sharpness and the delivered file"},"answer":null,"keyIdea":"Platforms resize, re-compress and strip the profile from every upload, so convert to sRGB, match the width they actually serve, sharpen slightly less than for final delivery, and give their encoder a high-quality input rather than one you already compressed.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"you-are-not-the-last-encoder","runs":[{"text":"You are not the last encoder"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"Once you accept that, the job changes: give their encoder the best possible input, and lose the least in their pass."}]},{"t":"h2","id":"the-three-things-their-pipeline-does","runs":[{"text":"The three things their pipeline does"}]},{"t":"p","runs":[{"text":"It resizes to a fixed width.","b":true},{"text":" 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."}]},{"t":"p","runs":[{"text":"It re-compresses.","b":true},{"text":" 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."}]},{"t":"p","runs":[{"text":"It strips metadata.","b":true},{"text":" 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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"matching-their-width-is-the-whole-trick","runs":[{"text":"Matching their width is the whole trick"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"giving-their-encoder-a-good-input","runs":[{"text":"Giving their encoder a good input"}]},{"t":"p","runs":[{"text":"Six things, in order of how much they help:"}]},{"t":"ol","start":1,"items":[[{"text":"Convert to sRGB and embed the profile.","b":true},{"text":" Costs nothing, and prevents the most visible failure."}],[{"text":"Upload at the platform’s own width","b":true},{"text":" where you can determine it."}],[{"text":"Sharpen a little less than you would for final delivery.","b":true},{"text":" Their re-encode will exaggerate halos, and a file sharpened for print arrives crunchy."}],[{"text":"Give it a high-quality JPEG or a PNG","b":true},{"text":", 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."}],[{"text":"Avoid fine dithered gradients and heavy grain","b":true},{"text":", which are what their encoder spends its budget on and loses first."}],[{"text":"Send as a document, not as a photo","b":true},{"text":", 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."}]]},{"t":"h2","id":"the-cases-where-none-of-this-is-enough","runs":[{"text":"The cases where none of this is enough"}]},{"t":"p","runs":[{"text":"Some things cannot be pre-empted, and it is better to know than to keep fighting."}]},{"t":"p","runs":[{"text":"Repeated re-uploads.","b":true},{"text":" 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."}]},{"t":"p","runs":[{"text":"Screenshots of your work.","b":true},{"text":" Every screenshot is a fresh capture at somebody else’s screen resolution with your metadata gone and no way to object."}]},{"t":"p","runs":[{"text":"Platform colour handling on phone apps.","b":true},{"text":" 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."}]},{"t":"p","runs":[{"text":"Automatic enhancement.","b":true},{"text":" 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."}]},{"t":"p","runs":[{"text":"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."}]}],"check":{"question":[{"text":"An editor compresses images hard before uploading to a social platform, reasoning that a smaller input means less for the platform to degrade. The posted images look worse than a colleague’s, who uploads large high-quality files. Why?"}],"options":[{"text":[{"text":"Large uploads are given priority in the platform’s encoding queue and receive a higher quality setting."}],"correct":false,"tempting":[{"text":"Invents a policy; the pipeline applies the same settings regardless of input size."}]},{"text":[{"text":"Their encoder re-compresses what it receives, so your artefacts are encoded again and the two losses stack."}],"correct":true,"tempting":null},{"text":[{"text":"Small files are upscaled to the platform’s fixed width, and upscaling is what introduces the visible damage."}],"correct":false,"tempting":[{"text":"Identifies a real step but the wrong one: the colleague’s files are downscaled to the same width and still come out better."}]},{"text":[{"text":"Heavier compression removes the ICC profile, so the pre-compressed files are interpreted in the wrong colour space."}],"correct":false,"tempting":[{"text":"Ties profile loss to the quality setting, when the platform strips metadata from every upload regardless."}]}],"order":[0,2,3,1],"why":null},"prev":{"slug":"serving-the-right-file","title":"One picture, six files, and letting the browser choose","minutes":9},"next":{"slug":"the-whole-job","title":"One bottle, one window, twelve minutes","minutes":12}}}