What actually happens to your file after upload
When you upload a product image, the platform runs it through an image pipeline: decode, resize into a set of standard widths, strip metadata, re-encode into one or more modern formats, and cache the results on a CDN. Your original is stored, but it is rarely what gets served.
The critical step is the re-encode. Lossy formats like JPEG, WebP and AVIF work by discarding detail the encoder predicts you will not notice. That prediction is made on the file it receives — including any artifacts already in it. If your source JPEG was saved at quality 70, the encoder treats the blocky edges of those artifacts as real image detail and spends bits preserving them, then introduces its own.
Each lossy save is a "generation." Two generations at quality 85 look noticeably worse than one generation at quality 75, even though the second file is larger. Always re-export derivatives from your master file, never from an already-compressed copy.
Resizing compounds the problem. A platform that downsamples your 3000px image to a 600px grid thumbnail is throwing away 96% of the pixels, and a poor downsampling filter turns fine texture — knit fabric, brushed metal, printed labels — into a shimmering mess before compression ever starts.
What each major platform does to product images
Exact parameters change without announcement, but the observable behavior across the big destinations is consistent enough to plan around.
| Platform | Typical served format | What it does to your upload |
|---|---|---|
| Amazon | JPEG / WebP | Generates many fixed-size derivatives; heavy compression on grid and mobile sizes, gentler on the zoom view |
| Shopify | WebP (auto) | Serves WebP to supporting browsers automatically; resizes to the width the theme requests |
| Meta (Shops/ads) | JPEG / WebP | Aggressive re-encode tuned for feed scroll; small text and thin lines suffer most |
| Google Shopping | WebP | Re-hosts and re-encodes; rejects images below minimum pixel dimensions outright |
| Etsy / eBay | JPEG / WebP | Multiple derivatives per listing; upload caps force downsampling of very large files |
The pattern: you get one shot at supplying a clean, high-resolution master, and every downstream size is derived from it automatically. Optimizing your upload for file size is optimizing the wrong variable — the platform is going to shrink it regardless.
The product types that break first
Compression artifacts are not evenly distributed. Encoders allocate bits to high-contrast edges and starve smooth areas, which means the failure modes are predictable by category.
Smooth tonal gradients are the worst case. A softly lit grey studio sweep contains hundreds of nearly identical tones; a lossy encoder collapses them into a handful of steps, producing visible bands across the backdrop. Fabric is the second worst — the encoder reads a knit weave as noise and smooths it away, so a merino sweater and an acrylic one start to look identical on the listing page.
Ingredient panels, nutrition labels and warning text sit right at the resolution where re-encoding turns letterforms into gray mush. If a shopper needs to read it, shoot it large enough that it survives a 4x downsample.
Upload specs that survive re-encoding
The goal is to hand the platform a file with headroom: more pixels than it needs, no pre-existing artifacts, and a color profile it will interpret correctly.
Common mistakes
- Uploading a JPEG already exported at quality 60–70 "to save bandwidth"
- Exporting derivatives from a previously compressed web file
- Sharpening heavily before upload, which the encoder then exaggerates into halos
- Shipping images in Adobe RGB or ProPhoto with no embedded profile
- Uploading at exactly the display size, leaving zero resampling headroom
What to do instead
- Export from the master at JPEG quality 90+, or supply PNG where the platform accepts it
- Regenerate every size from the original master file
- Apply only light output sharpening, sized for the final display width
- Convert to sRGB with the profile embedded
- Upload the longest edge at 2000–3000px, well above the largest served size
Two more habits pay off immediately. First, keep the background genuinely flat where you can — a pure, even white or a solid tone compresses almost losslessly, while a subtle vignette invites banding. Second, avoid stacking noise reduction and sharpening; both rewrite exactly the high-frequency detail the encoder is already fighting over.
If you use AI tools to generate or retouch product imagery, export the result at maximum quality and keep it as your master. Tools like Retouchable produce a clean, high-resolution file precisely so the platform's compression pass has something with headroom to work from.
How to test what your customers actually see
Do not judge quality in your editing app. Judge it on the live listing, at the size a shopper sees, on the device they use.
- Pull the served file, not the original. Open the live product page, right-click the image, and copy its actual URL — note the format and dimensions in the filename or query string.
- Compare at 100%. Put the served derivative next to your master at the same display size. Look at backdrop gradients, fabric weave and any text first.
- Check the grid thumbnail separately. It is compressed hardest and it is the image that earns the click.
- Check mobile. Most platforms serve a different, smaller derivative to phones, and most of your traffic is there.
- Re-test after any pipeline change. Theme updates, CDN changes and marketplace policy updates all shift the parameters silently.
If a category consistently looks bad after re-encode — glassware, dark tonal shots, anything with a gradient sweep — change the shot, not the export settings. A flat, evenly lit background survives compression that a moody gradient will not.