A pre-upload checklist for listing images
Most listing image rejections come from a small number of causes, and almost all of them are visible before you upload. The problem is that they are visible in different places, some in the file, some in the metadata, some only in a pixel value, so nobody checks all of them.
This is the order that catches the most problems soonest.
Before you export
1. Is the product actually all in frame? Sounds trivial. It is a common cause of reshoots because a cropped handle or lid is easy to miss on a camera screen and obvious at full size.
2. Are the highlights intact? Zoom to the brightest part of the product. If it is flat 255 with no texture, that detail is gone and no export setting recovers it.
3. Is the white balance consistent across the set? Photographs of the same product range should match. Auto white balance drifts between shots, so a red product and a blue product photographed on the same sweep can come out on two different whites.
In the file
4. Are the four corners pure white? For Amazon and Walmart main images this is literal: RGB(255,255,255). Sample the corners with an eyedropper. 250 is not 255, and the difference is invisible to you and decisive to them. This is the single most common rejection cause.
5. Is the longest edge above the zoom threshold, not just the minimum? Marketplaces publish two numbers and they get confused. Below the minimum, the upload fails. Above the minimum but below the zoom threshold, it publishes silently without the zoom feature, which is what shoppers use to decide whether the stitching looks right.
6. Is the file under the size limit? Walmart in particular asks for a large image and a small file at once. If your export tool lowered quality to fit, check what it settled on: below about quality 60 with chroma subsampling on is where compression can push corner pixels off pure white.
7. Is it sRGB? If the file is tagged Display P3 or has no profile at all, colours can arrive flatter than you approved. Convert to sRGB on export, convert, not assign.
8. Is it the right way up? Particularly for phone photographs. A portrait shot that looks correct in your file browser can upload rotated if the orientation tag is stripped or applied twice.
Rules that vary by platform
9. Watermarks, borders and text. eBay prohibits watermarks of any type on every listing photo, including ownership attributions. Amazon and Walmart prohibit them on the main image. Getting this wrong is not a quality issue, it is a policy violation.
10. Props and packaging. Main images generally must show the product alone, without props, backgrounds or accessories not included in the sale. A mug photographed with coffee in it and a book beside it is a supporting image, not a main one.
11. Does the product fill enough of the frame? Amazon asks for roughly 85% on main images. Too small and the product looks lost in the search grid; too large and it can push corner pixels off white.
Running the checks in the right order
The order above is not arbitrary. It moves from cheapest to most expensive to fix.
Checks 1 to 3 are about the photograph, and failing one means a reshoot. There is no point sampling corner pixels on an image whose highlights are blown, because you are going to reshoot it anyway.
Checks 4 to 8 are about the file, and failing one means re-exporting. Cheap, provided the photograph is sound.
Checks 9 to 11 are about the rules, and failing one means changing a setting, often for the whole batch at once, since a watermark or a fill target applies to every image you produced.
Working the other way round is how people end up reshooting a product whose only problem was an export setting.
What to do when a whole batch fails
If one image has a problem, fix it. If several do, stop and find the cause before fixing any of them.
A batch is produced by a process, and a process that produced one bad image produced others by the same mechanism. Fixing eleven images individually and leaving the twelfth is the usual outcome of treating each as a separate incident.
The commonest batch-level causes:
- An export preset changed, or a different one was used than last time.
- The lighting moved between sessions, so the background sits at a different value.
- A file size limit forced quality down across the whole run, taking corner pixels with it.
- The source folder mixed two shoots with different white balance.
Each of those is a single fix applied once, rather than four hundred fixes applied individually.
Where each check is easiest to run
Knowing where to look saves as much time as knowing what to look for.
| Check | Where |
|---|---|
| Product in frame, highlights intact | Photo viewer at 100% |
| Corner pixels | Eyedropper in any editor, or automatically |
| Dimensions and file size | File properties, or a folder listed in detail view |
| Colour profile | File info panel, or ExifTool |
| Orientation | Open it, if it looks right in more than one program, it is |
| Watermarks, props, text | By eye |
| Fill percentage | By eye against a square guide, or reported by a tool |
The corner check is the one most worth automating, because it is the only one that is both invisible to the eye and decisive.
The filename check nobody does
If you are bulk uploading, the filename is how the marketplace matches images to listings. Two files with the same name means one silently overwrites the other, and you will not find out until a listing shows the wrong product.
Check that every filename in the batch is unique, and that the pattern includes something distinguishing every variant you produced, not just the SKU, if you made several sizes per SKU.
Doing this at scale
Eleven checks across four hundred images is not a manual job. Which is roughly the argument for running them automatically: PrepShot verifies the corner pixels of the encoded file rather than the buffer before encoding, because the encoded file is what the marketplace receives and they are not always the same thing.
But whether you automate it or not, the order matters. Checking corner pixels before checking whether the product is in frame is a wasted pass.
A note on the checks you cannot automate
Four of the eleven above need a person, and it is worth knowing which so you do not assume a green tick means compliant.
Is the product in frame and undamaged? No tool knows what your product is supposed to look like.
Are props present that should not be? A tool can measure a background; it cannot judge whether the wooden board under your soap counts as a prop.
Does the image represent the product accurately? The most consequential check and entirely human. A colour that photographs slightly off, a size that reads larger than it is, a finish that looks glossier than the item, none of these are rule violations and all of them produce returns.
Is this the right image for this SKU? Attaching the wrong photograph to a listing is a filename problem with a commercial consequence, and no automated check catches it because both files are individually valid.
So the automated checks handle volume, and a person spot-checks a sample. Ten images looked at properly out of four hundred is far better than none, and it is the only way the four above get done at all.
Doing it for a supporting image set
The eleven checks above are written for a main image, which carries the strictest rules. Supporting images are looser, and the difference is worth knowing so you do not apply main-image standards to all eight.
Supporting images generally may have a background other than white, include props and lifestyle context, carry text and infographic overlays on most platforms, and show the product in use or at a scale that a plain shot cannot convey.
They generally must still meet the dimension minimum, the file size cap, and, on platforms that prohibit them outright, such as eBay, the watermark rules.
So for supporting images the checklist collapses to about four items: in frame, sharp, correct dimensions and file size, and no watermark where prohibited. That is a much faster pass, and it means the careful checking is concentrated where it actually decides acceptance.
Keep a note of what you checked and when
Marketplace requirements change. Any checklist, including this one, is accurate on the day it was written and decaying from then on.
Write down the date you last verified a figure against the platform's own documentation. A requirement with no date beside it is a value someone assumed was still right, which is how a whole batch ends up wrong at once.