White background product photo: why your white is not 255

White is a measured value, not a colour

A white background product photo is not a design choice. It is a number. Amazon asks for pure white, and pure white means RGB 255, 255, 255: the highest value a pixel can hold. What you photograph in a studio rarely reaches it, because a camera measures light and light never falls evenly across a backdrop.

On 14 August 2026 we measured 245 main images on bol.com across eight categories. Only 30 of them still had enough visible margin around the product to read the background at all. Of those 30, five hit pure 255.

That number does not matter on bol, because bol stopped checking images against its own image rules on 1 July 2025. It starts mattering the moment the same file travels somewhere else. Amazon does check, and can keep a listing out of its search results. Google draws a hard floor from 31 January 2027 and is the only one of the three that also sets a ceiling.

So design your image for the strictest of the three, not the easiest. Otherwise the channel you watch least ends up deciding how your product looks everywhere else.

Why does a white background product photo almost never hit 255?

Because a camera measures light rather than assigning colour. A white backdrop reflects light, and that light is never even. It falls away at the edges, the product casts a shadow behind itself, and the lens adds vignetting, so the corners sit darker than the centre. The result reads as white and measures just under it.

Brighter lighting does not fix this. You raise the exposure of the whole frame, including the product, and you lose detail in its lighter areas. A white T-shirt on a backdrop you pushed to 255 with light has no seams left. That is a worse photo.

The route that works runs through post-production. You shoot on a backdrop that is clearly lighter than your product, then lift only the background region to 255. The product stays untouched. It costs a couple of minutes per image, it is a standard operation, and it is exactly the step that disappears when someone hands over files straight out of the camera.

An AI background remover will reach 255, incidentally. On the search term this article covers, most of Google's first page is made up of that kind of tool. What it does not solve is the edge: halos around hair, glass and transparent parts, and a product pasted tight against the frame after cutting out. You trade a background problem for a framing problem, and the second one shows up in more channels than the first.

223 of 245 bol images fill the frame too far

We pulled 245 main images as bol itself serves them, across eight categories, and measured three things per image: how much of the frame the product fills, whether it touches the edge, and whether the image is square.

That first line is not seller sloppiness. It is bol. Bol crops white space away automatically before an image appears on the platform, and documents that it does so. You upload a square image with clean margin, and bol serves a cropped version in which the product runs to the edge.

For bol that works well. Every product reads at the same size, the grid stays calm, and the customer sees the product without detours. The crop is not a presentation choice that stays on the platform, though. The file bol serves is a different file from the one you delivered: in our measurement, 170 of the 245 images were no longer square after that processing step.

On bol you see the result after the crop. You never see what you uploaded. Anyone assembling an image library based on how things look on bol is building the whole set from one platform's output.

Three platforms measure the same file in three ways

The differences are small to read and decisive in outcome.

Read the frame fill row again. That is where the money sits. Amazon sets a floor for how much of the frame your product must fill and leaves the top open. Bol sets neither and crops on your behalf. Google is the only one putting a ceiling on it.

An edge-to-edge photo is therefore right on two of the three channels and too full on the third. And the channel pushing you toward that ceiling is bol, through processing that happens after upload and that you never see.

The size row behaves the same way. Amazon counts the longest side, so all 245 images in our measurement clear it comfortably. Google counts both sides. Once the new floor applies on 31 January 2027, 224 of those same 245 images fall through it. That is a different measurement from the 223 above and coincidentally almost the same number: the first is about frame fill, this one about pixel dimensions.

We have written before about what applies on the Amazon side of image requirements. What was missing there is this layer: that the three channels diverge at the top end, and that nobody tells your client.

Why your bol photo quietly weakens your Shopping feed

Take the most common route at a mid-sized web shop. A photographer delivers a set. The set goes to bol. Someone later pulls the images off bol to fill the web shop, since they are already sitting there neatly on white. That shop's feed goes to Merchant Center.

What happens next: the image reaching Google is the bol version. Cropped to the edge, often not square, no margin. In our measurement, 223 of 245 images sit above Google's ceiling and 8 of 245 sit inside the band it advises.

Nobody notices, because no error appears. A disapproval in Merchant Center follows a hard requirement. Advice you fail to meet only costs you placement, and you see that in a quarterly report nobody connects to the photos.

The design rule that follows costs nothing: deliver square at source, with margin, at 1500 pixels minimum. Leave cropping to the platform that wants to crop. Bol crops itself and is happy. Amazon counts the longest side and is happy. Google gets margin inside the band it advises. It does not work in reverse, because you cannot conjure margin back out of a tightly cropped file.

This is the same mistake we keep seeing with product content across channels. Optimisation follows the channel that responds fastest, and that is rarely the channel with the strictest standard.

Why is your old photo still in Google Shopping six weeks later?

Because you most likely replaced the file instead of publishing a new path. Google Merchant Center is explicit: update the content of an image while keeping the same URL and it can take considerably longer for the system to detect the change. Put the new image on a new, unique URL in the image_link attribute and a recrawl usually follows within three days.

Translate that into practice. A client commissions a new set in September for the autumn range. The developer places the new files neatly on the same paths, because it keeps the media library tidy. Six weeks later the summer photos are still in Google Shopping while the campaign already runs on the new imagery. The photos are paid for, the shoot has happened, and the channel shows the previous set.

So we hold it as a delivery rule: never replace a file, publish a new path. It applies to Merchant Center, and for exactly the same reason to any content delivery network that holds files for a long time. Your own shop's cache behaves the same way, with the same delay.

Execution is a naming convention. Put a version or a date in the filename, so a new set automatically lands on a new path. It costs half an hour to set up and saves weeks on every shoot after that.

One more reason to sort this out before a reshoot: in the two documented cases we found of a suppressed Amazon listing, it happened on a change to a listing that was already running, not on first upload. Two cases are not proof of a pattern, but it is the moment you touch files while revenue depends on them.

Does your image even reach the machine?

This is the layer underneath everything above. A photo that is technically correct but served in a way nothing can read does little in the channels now being added.

Google's documentation for merchant listings asks for multiple images in three aspect ratios: 16x9, 4x3 and 1x1, with a floor of 50K pixels when you multiply width by height. Google also advises putting product structured data in the initial HTML, because markup generated by JavaScript makes shopping crawls less reliable.

We checked 55 product pages at 11 Dutch web shops. Of those 55 pages, 16 have no usable image field in the product schema in the initial HTML, and 45 serve zero or one image. Multiple images in multiple ratios is never achieved at 9 of the 11 shops we measured.

At five Dutch Shopify brands we also looked at 522 images on the route agents are pointed to. All 522 had an empty alt text, without exception. Alt text has been treated as an accessibility checkbox for years. It is now the channel through which a machine reads what is in the photo, because the descriptive fields in the image sitemap have been dropped and only the location still counts.

Meanwhile the side of this that matters is growing fast. Google reports more than 20 billion visual searches per month through Lens, and 20% of those are shopping-related. Those are searches that start with a camera instead of a keyboard. There is no textual optimisation for that. There is only imagery.

If you are wondering which secret trick goes with it: there is none. Google writes in its own documentation on AI features that there is no special schema.org markup you need to add, and in the same paragraph explicitly names high-quality images as a factor. The feed and the photos. Nothing beyond that. We worked this out in our article on visual discoverability through Google Images.

The check we run before delivery

We made this a fixed step in every product photography engagement, because it costs us minutes and saves the client a listing. The check runs on the final files, before they enter any channel.

At Screenmate and KG Goods delivery ran across several channels at once, and this list came out of that work. None of it is complicated. It is simply rarely done: in six years we have delivered hundreds of listings and never once had a client ask about a background value. The conversation is about how the photo looks, while the outcome is decided by how it gets measured.

What to do on Monday morning

Four steps, in this order, and you have an answer within the hour.

Put your own main image as bol serves it next to the file you delivered. If the crop differs, your margin is disappearing at upload and the bol image is not your source file.

Then open one image in an editor and read the pixel value in a corner of the background. If it says 255, 255, 255, you are done. If it says anything else, you know why a replaced set can stall on Amazon.

Next, check where the images in your product feed actually live. If they are the same files that go to bol, you are handing the strictest channel a file processed by the most permissive one.

Finally, agree with whoever manages your files that a new set gets a new path. That is the cheapest of the four and the only one that saves weeks.

Want an existing set measured before you book a new shoot: we run that as a standalone check within product listing design engagements. Book a call and bring one listing you already suspect.