"Image too small" in Merchant Center: two warnings, two deadlines, and what Shopify does not tell you about image size

Short answer. Merchant Center uses one name, "Image too small", for two different problems. Below 100 x 100 pixels, or 250 x 250 for apparel, your product is disapproved today. Between that and 500 x 500 it is only a warning, until Google enforces a 500 x 500 floor for every product on January 31, 2027. Shopify documents a maximum image size and no minimum, so nothing in either admin compares your images against the floor.

Want to know if your store has this right now? Check my store, free 2 min · read-only

A warning appears in Merchant Center against products that have been selling for years. The photographs look fine in your store, they look fine on the product page, and Shopify admin has no opinion about them at all. Nothing is disapproved, nothing has stopped, and the warning does not say what to change.

This page is the reference for that warning. It covers what Google actually measures, the two different things its one label can mean, and the date attached to each. It then covers what Shopify's side documents and what it does not, and how to find the affected products when neither admin will show you a pixel dimension. Every figure below is quoted from Google's or Shopify's own documentation, fetched on November 4, 2026, or measured on live Shopify storefronts the same day with the sample size attached.

Two warnings, one name, and only one of them costs you today

Google's own page for this issue describes the cause in one sentence: "The image submitted for this product is too small to be used in an ad or a free listing." That is a disapproval. The thresholds it is measured against are the ones in force now, and they are lower than the 500 the warnings talk about. For clothing, "For apparel products, images must be at least 250 x 250 pixels and can't be larger than 64 megapixels." For everything else, "For all other products, images must be at least 100 x 100 pixels."

A 100 x 100 floor is small enough that very few real product photographs fall under it. Which is why the second warning exists, and why it is the one you are probably looking at. Google is raising the floor: "We recently announced new image size requirements of at least 500 x 500 pixels for all product images." The date is stated on the same page, "Enforcement of the new requirements will begin January 31, 2027." In the meantime Google is reporting rather than refusing: "Starting July 2026 you will see warnings on images larger than the minimum requirements but smaller than 500 x 500."

Those warnings have therefore been accumulating since July 2026 against products that are still fully eligible, and will keep accumulating until they are not. Google's history view labels that second case differently, "Image too small for upcoming enforcement.", but the issue list itself gives both the same headline. So the first question to answer is not how to fix it. The question is which of the two you have, because one is costing you listings this afternoon and the other costs you nothing until a date three months away.

One qualifier, because it cuts against reading the deadline as absolute. Google reserves some room to rescue an undersized image itself: "In some cases, we may serve an optimized version of images below 500 x 500 when possible." It does not say which cases, so it is not something to plan around, but a warning is not a guaranteed loss either. There is also a third threshold that has nothing to do with either warning and is easy to mistake for one: "For YouTube Shopping Ads, images must be at least 500 x 500 pixels to serve on TV." That 500 x 500 has been in place independently of the 2027 change.

Every image rule Google applies, in one place

Size is the rule with a date on it, so it gets the attention. There are several others, and they disapprove a product outright rather than warning it. Taken from the image link [image_link] specification, all of it fetched today:

The last four are worth reading twice if you are about to solve a size warning by padding. An image brought up to 500 x 500 by adding white space around a small photograph satisfies the pixel count and moves you toward the clean-view rule instead, which is a disapproval rather than a warning. Resizing is not the same operation as re-uploading, and only one of them produces an image Google will accept.

The placeholder rule also catches a specifically Shopify-shaped case, which the probe in section five turned up on a live store: a product page can declare Shopify's own "no image" asset as the product image in its structured data while displaying a real photograph to shoppers. That is not a small image. A generic graphic that does not show the product is named in the spec as its own violation, and it stays invisible unless you read what the page declares rather than what it renders.

StoreCanary checks this on your store

Not sure which of your products sit under the coming floor? We read every image URL your product pages declare, measure the largest one that actually responds, and flag the products whose biggest available version is under 500 pixels on a side, plus any whose declared image returns an error instead of a picture: read-only, no admin access, about 2 minutes.

Scan my store for free

What Shopify documents, and the two places the specs do not meet

Read Shopify's side next, because the shape of it explains why nobody caught this earlier. Shopify's product media documentation states a maximum and a recommendation, and no minimum at all. The maximum: "Your product and collection images can be any size up to 5000 x 5000 px, or 25 megapixels." The file-size limit: "Product and collection images need to have a file size smaller than 20 MB to be added to Shopify." And for square images, "a size of 2048 x 2048 px usually displays best."

A recommendation is not a gate. If a supplier sends a 300 x 300 photograph, for example, Shopify will accept it, store it, display it and submit it, and never once mention that another company has a floor it falls under. That is the whole mechanism: the system that holds your images documents a ceiling, the system that judges them documents a floor, and no screen in either one puts the two side by side.

Line the two specifications up and they disagree in exactly one place that can bite. Google refuses a file above 16MB; Shopify accepts one up to 20MB. Any image between those two numbers is a file Shopify will take happily and Google will reject as "Image too big". The megapixel limits run the other way and therefore cannot bite: Shopify's 25 megapixel ceiling sits well inside Google's 64, so an image Shopify accepted can never be too many pixels for Google. A Shopify setting and a Google specification disagreeing in a way neither admin surfaces is a recurring shape rather than an accident here; the wrong currency reaching Google is the same mechanism applied to a value instead of a file. The format lists overlap but are not identical, and Shopify's own page is explicit about its wider range: "Other accepted file types are TIFF, BMP, GIF, SVG, HEIC, and WebP." SVG and HEIC appear on Shopify's list and on neither of Google's.

Confirm it yourself in five minutes

Do this on the Google side first, because it is the only place the measurement actually lives.

  1. Open Merchant Center and go to Products, then the Needs attention tab. Google's instruction for the bulk case is to "Download the list of affected products (.csv)" from there, then "Reupload your corrected product data to Merchant Center using your chosen upload method."
  2. Read the issue name carefully, and check the history view. The issue list shows "Image too small" for both cases. The history view is where the second one is named "Image too small for upcoming enforcement.", and that string is the difference between a product that is currently disapproved and one that is currently fine.
  3. Do not assume the page is at fault. This warning is about a file, not about whether Google can reach the page. If the issue list also shows a landing-page problem, that is a different check with a different cause, covered in product page unavailable in Merchant Center.
  4. Count the affected products before you plan anything. Three products is an afternoon. Three thousand is a re-upload, and whether the originals even exist at 500 pixels is then the real question.
  5. Check an original, not a rendering. In Shopify admin, open the product's media and the image itself, rather than judging by the thumbnail in the product list. The product list thumbnail is generated at a size of Shopify's choosing and tells you nothing about the file behind it.

On the page side there is one honest check and one trap, and the next section is about the trap. The check: open the product page's source, find the Product block in its structured data, and look at every URL in its image value rather than the first. If the largest of them is under 500 pixels on a side, the original behind it almost certainly is too. If a larger one is there, the original is fine and the small URL is only a resized copy. Which image Google picks for a search result is a separate question with separate signals, covered in the wrong product image showing on Google.

The size on your own page is usually not the size being measured

This is the part that makes the check harder than it sounds, and it is measurable. On November 4, 2026 we took 34 candidate storefronts; 23 identified themselves as Shopify-served in the response header, and 22 of those exposed a readable public catalogue and at least one fetchable product page. Across those 22 stores we parsed 66 product pages, read every image URL declared in the Product structured data, and measured each one by reading the dimensions out of the file's own header bytes. Counts, with that sample size attached, and never as rates:

  • 54 of the 66 pages declared at least one readable image in their Product block. The other 12 declared none: two stores served no Product structured data at all on any of the three pages read, two more served none on some pages and not others, and one served a Product block with no image property on all three.
  • 27 of those 54 pages declared more than one image URL, across 11 of the stores. In several cases the extra URLs were not extra photographs but the same photograph at different widths.
  • On 12 pages, across 4 stores, the first declared URL measured under 500 pixels on a side. One store's image value was a ladder of the same photograph at 100, 300, 600 and 900 pixels, in that order, so the first entry was a 100 x 100 thumbnail.
  • On only 6 pages, across 2 stores, was the largest readable declared URL under 500. So reading the first URL instead of the largest would have reported twice as many stores as having a problem.

Then the two stores that survived that filter both turned out to fail for a reason other than image size, which is the result worth having. On one, all three pages declared a single URL ending in a _450x450 suffix, while the page's own og:image pointed at the unsuffixed original. Those three originals measured 3949 x 4936, 3276 x 4096 and 960 x 1200. The store has the resolution; its structured data declares a 450-pixel copy of it. On the other, all three pages declared the same Shopify "no image" placeholder asset at 348 x 348, while og:image pointed at a real product photograph, measuring 1374 x 1722, 2000 x 2000 and 1374 x 1722. Neither store has a small product image. Both would be flagged by a check that reads a page's declaration and stops there.

So: zero of the 22 stores had a product photograph whose largest available version was under 500 x 500. That null needs its caveat stated plainly, because it cuts against us: established direct-to-consumer brands are the stores least likely to be carrying a 300-pixel supplier photograph, so this is good evidence about what Shopify themes declare and weak evidence about how common undersized originals are across merchants generally. We are not claiming the defect is rare. We are reporting that in this sample we could not find one, which is a smaller and different statement.

What the sample does establish is the method. A page's declared image size is a theme decision, not a fact about your catalogue, and the first URL in the list is the least reliable of the lot. The CDN mechanics behind those multiple addresses for one photograph are covered in the article on which image Google shows; what matters here is only the rule that follows from them, which is to measure the largest and ignore the rest.

Why adding ?width=500 is not a fix

Shopify image URLs carry their size in the URL, so the obvious move is to ask for a bigger one. It does not work, and Shopify documents why in one sentence: "Regardless of the specified dimensions, an image can never be resized to be larger than its original dimensions." The image_url filter will accept any width you ask for, up to "a maximum of 5760px." It then quietly returns the original whenever the original is smaller.

We saw that behaviour in the sample. One store declared five image URLs that all requested width=1200; measured, they came back at 947 x 800, 1080 x 720 and 1200 x 1014. The parameter is a ceiling request, not a promise, and the only thing that determines whether a 500-pixel version exists is whether the file uploaded to Shopify was at least 500 pixels.

Which means the fix is never in the theme. It is a re-upload, product by product or in bulk, of originals that clear the floor. Google's instruction for the single-product case says the same thing in its own words: "Replace your current product images with images that meet our requirements." Google also points at tooling of its own on the same page: "You can increase resolution, remove backgrounds, and generate a scene for your products using Product Studio", "which is available for Merchant Center users and within the Google & YouTube app in Shopify." Whether an upscaled image still offers the "unobstructed, clean view" the spec asks for is a judgement to make per product rather than in bulk.

The fix, in order

  1. Separate the two warnings before doing any work. In Merchant Center, check whether the history view names your issue "Image too small for upcoming enforcement." If it does, nothing is disapproved yet and your deadline is January 31, 2027. If it does not, products are being refused now for falling under 100 x 100, or 250 x 250 on apparel, and that is today's work.
  2. Export the affected list. Download the .csv from the Needs attention tab rather than working from the on-screen list, so you have product IDs to reconcile against your catalogue.
  3. Measure the originals, not the page. Check the file in Shopify's product media. A URL on your storefront carries whatever width the theme asked for, so it cannot tell you whether a compliant original exists.
  4. Re-upload, do not re-parameterise. Shopify will not return an image larger than the original, so the only fix is a larger source file. Aim at Google's recommendation of 1500 x 1500 or above rather than at the 500 floor, so the next threshold change costs nothing.
  5. Do not pad to reach the number. Adding white space to make 500 x 500 trades a warning for the promotional-elements and clean-view rules, which disapprove rather than warn.
  6. Check what your structured data declares while you are there. A Product block with no image property, or one declaring a placeholder asset, is a separate problem from size and is not reported by the same warning. The broader question of which structured-data warnings matter is covered in which Shopify structured data warnings to fix, and which Search Console report they appear in is in merchant listings versus product snippets.
  7. Re-upload the corrected data and expect a wait. Google's bulk instruction is to reupload corrected product data by your usual method. How long each surface takes to reflect the change is covered in how long Google takes to update a Shopify product.

The reason to do this before January rather than after is not the deadline itself. It is that the warning is the only notice you get, it has been issuing since July 2026 against products that still look healthy everywhere else, and the thing it is warning about, the size of the file somebody uploaded, is not visible on any screen in either system. The same is true of the next product you add, and of the next supplier import after that: nothing in Shopify admin will mention the floor, and nothing in Merchant Center will mention it until the product is already in the list. For the wider map of failures that behave this way, see the 11 reasons Shopify products stop showing on Google, and for the closest neighbour to this one, where the feed and the page disagree about a value rather than a file, Merchant Center price mismatch on Shopify.

Is this happening on your store right now?

Merchant Center will not tell you until it disapproves a listing. The product is live in your store, and Google Shopping is showing a different price, the wrong availability, or nothing at all. The only way to know is to check the feed the way Google reads it.

  • 90+ checks, the way Google reads your product feed. Price and availability mismatches, missing identifiers, redirect chains.
  • Read-only. No app to install, no admin access, nothing changes on your store.
  • The exact fix for each page, in plain English, so you or your developer can act the same day.

Across full-catalog scans of more than 90,000 Shopify product pages, about 1 in 4 stores had at least one critical Google visibility issue.

Scan my store for free

Free scan: issue types, counts and first fixes. Full report on every product page, not a sample: $49 once, no subscription.

Next in this cluster