The Shopify Collection Grid Fix That Kept Doing Nothing

Quick answer: the widely-shared CSS fix for a broken shopify collection grid is written for Dawn 2.0. If your store runs Dawn 7 or later, or Horizon, or a premium theme, the selector points at a class name that no longer exists in your theme. Paste it in, save, refresh, nothing changes. The fix is not wrong. It is aimed at a target that has moved three times since the community first wrote it down.

We opened the store on a Tuesday and the collection page looked like a shelf someone had been rearranging for years. Portrait photos next to square ones next to lifestyle shots with a hand in the frame. Some cards were tall, some were short, product titles floated at seven different heights across a single row. The owner had already tried the three settings the theme editor offered. She had already pasted CSS from three separate community threads. Nothing had done anything. She wanted to know if she was missing a setting.

She wasn't. What follows is what we actually checked, in the order we checked it, and where the real problem was hiding.

What we checked first

The obvious thing to check on any misaligned collection grid is the image ratio setting. In the theme editor, under the Collection template, there is a field called Product image ratio (Dawn) or Product media aspect ratio (Horizon). It has four options: Square, Portrait, Landscape, and Adapt to image.

The owner had already cycled through all four. She was right about the outcome. Square and Portrait produced a tidy grid but cropped tall photos so aggressively that a candle in one product shot became a shapeless amber blob. Adapt to image showed the full photo but staggered the rows. Product titles landed at different heights, prices sat below different amounts of white space, and add-to-cart buttons stopped forming a scannable column. There is no fifth option in the admin.

This is the two-choice deadlock most merchants hit on a mixed-ratio catalog. It is what the admin was designed to do, and there is no third setting hiding behind an advanced toggle. If your catalog is one photographer working from one background, none of this happens; you set Square and go. Multi-supplier catalogs, dropshipped catalogs, and catalogs that grew over three years all land in the deadlock, because no supplier coordinates ratios with any other supplier.

So the theme setting was not the problem. It was the ceiling.

Where the trail almost ended

The next step is the community CSS fix, and this is where most investigations of a broken shopify collection grid end - with the writer declaring the fix works and moving on. We tried it. It did not work.

The fix she had pasted, the one that shows up in the highest-ranked community thread for this exact problem, is this:

.card__inner .media--transparent img {
  object-fit: contain;
}
.card__inner .media--transparent {
  background-color: #fff;
}

Paste that into the theme's Custom CSS field, save, hard-refresh the collection page. In her store, the images did not change. Same crops, same stagger. No console error, no admin warning, just a fix that did not fix anything.

At that point we had two working hypotheses. Either the CSS was correct but something was overriding it, or the selector was pointing at nothing. We opened DevTools to find out which.

The clue we almost missed

Right-click on a cropped image, choose Inspect. In her store, the image was an <img> element nested inside a <div class="product-media-container">, which sat inside a <product-card> custom element. There was no .card__inner anywhere in the DOM. There was no .media--transparent anywhere in the DOM. The CSS rule had matched zero elements from the moment it loaded.

This is the fingerprint of a Horizon store. The community fix is written for Dawn. Not just for Dawn in general, but for Dawn 2.0 specifically. The class names Dawn used in 2021 are not the class names Dawn uses now, and none of them are what Horizon uses.

If we had trusted the fix and moved on, we would have told the owner the problem was probably CDN-side and there was nothing to do without recompressing every image. That would have been wrong. The problem was that the fix and the theme were speaking different languages, and neither the fix nor the admin says so.

Three failures wearing the same mask

Once we started looking with fresh eyes, we realized that "collection grid images look wrong" collapses three separate problems into one symptom. In her store and in a handful of others we have inspected since, all three showed up in various combinations, and each one requires a different fix.

The first is aspect-ratio inconsistency, the one everyone knows about. Portrait and landscape photos in the same grid with Square or Portrait settings selected produce cropping; with Adapt to image selected they produce stagger. This is what the CSS fix targets.

The second is app injection. Certain variant-swatch, badge, and quick-view apps insert their own DOM elements into each product card on the collection page. The insertion happens about a second after the initial render, which is why the grid looks aligned when the page first paints and then jumps out of alignment as you sit there staring at it. We saw this on a Savor-theme store the following week; the offender was a color swatch app whose stagger was pixel-identical to what an aspect-ratio problem produces. Uninstalling the app fixed the grid immediately, and no amount of CSS object-fit: contain would have touched it.

The third is CDN pre-cropping. Shopify serves images through its CDN, and the URLs in your <img> tags often carry size parameters appended after the filename, like _600x600 or _medium. Those parameters mean the CDN has already resized the file before it reaches the browser. If the resize is a hard crop rather than a fit-to-box, no CSS on the client can restore the missing pixels. This is uncommon but real, and it is the failure mode Paul Newton flagged in a 2022 community thread that most fix-seekers never find.

The diagnostic difference matters. If the stagger is present the moment the page paints, it is aspect ratio; try CSS. If the stagger appears about a second after paint, it is app injection; disable third-party apps one at a time on a duplicate theme until the grid stops jumping. If the CSS rule is definitely matching the right elements and the images still crop, inspect the actual image URL for size suffixes; if the CDN has already cropped, the fix is at the source, not in the browser.

The selectors that moved without telling anyone

Once we had ruled out apps and CDN pre-cropping, the fix was CSS. But we still had to get the selector right, and that is what almost nobody writes down.

Dawn's class names for the product card have changed at least twice in the theme's history. Horizon uses different class names again. Premium themes each pick their own. A rule that targets .card__inner .media--transparent img is a Dawn 2.0 rule; it matches nothing on a current Dawn store because that class does not exist there anymore. If you copy the highest-ranked answer from a community thread and paste it in, and your store is not on the specific theme version that answer was written for, you get the exact experience the owner had: nothing.

Here is what actually maps to what, based on a handful of stores we have inspected this year and the fixes that have gone into the theme code editor:

Theme	Version	Selector for the product image on the collection grid
Dawn	7 and later (current)	.card__media .media img
Dawn	2.0 through 6.x	.card__inner .media--transparent img
Dawn	pre-7 legacy (grid__image)	outdated, no longer exists in current Dawn
Horizon	any	.product-media-container img
Publisher	current	.product-card-wrapper img
Minon and similar with inline --aspect-ratio	any	[style*=--aspect-ratio] img
Legacy pre-Dawn (Debut era)	any	.template-collection .product-img img

The way to be sure which one is yours: right-click the broken image on your live collection page, choose Inspect, and read the class name on the closest wrapping <div> that has one. If your DOM shows product-media-container, you are on Horizon. If it shows card__media, you are on Dawn 7 or later. If it shows card__inner with media--transparent, you are on an older Dawn that has not been upgraded. Any selector that does not appear in your DOM will silently miss.

What actually works

Once you know the right selector, the fix for a mixed-ratio shopify collection grid is a single rule. The whole thing lives in one place: theme customizer, Theme settings, Custom CSS.

For a current Dawn store:

.card__media .media img {
  object-fit: contain;
}
.card__media .media {
  background-color: #ffffff;
}

For a Horizon store:

.product-media-container img {
  object-fit: contain !important;
}
.product-media-container {
  background-color: #ffffff;
}

The !important on Horizon is not decorative; several third-party apps we have looked at inject their own object-fit: cover directly onto the image element, and without !important the injected rule wins the specificity race. Dawn stores can usually go without it.

If you would rather keep the natural aspect ratio and only stop the product titles from staggering, there is a second-known-good pattern for Dawn that anchors the title, price, and add-to-cart to a consistent row inside each card:

.collection .card--standard>.card__content .card__information {
  align-self: flex-end !important;
  grid-row-start: 3 !important;
  justify-self: flex-start !important;
}

Set the theme's image ratio to Adapt to image, then paste this in. Card heights will still vary, because the images are still their natural heights, but the row of titles and prices below the images will line up across the row. This is the "third path" that no admin setting suggests. It suits catalogs where the images vary by a little and you would rather have some vertical breathing room than uniform letterbox space around every non-square photo.

If you tried the CSS above and something is still off, you probably have one of the app-injection variants and the right next step is a duplicate theme with apps toggled off one by one, not more CSS. If you want a second pair of eyes on the DOM before you go touching your live theme, the first fifteen minutes of a help1 chat is free and this is a fingerprint we recognize on sight.

The channel we forgot to check

Two weeks after we shipped the fix on the original store, the owner emailed us. The website looked great. The problem was Facebook.

Facebook Catalog was still showing her images cropped the wrong way, and the Google Shopping preview looked the same. She was not wrong; both were pulling the original image files directly from Shopify's CDN via the product API, without ever hitting her storefront CSS. Our fix normalized what her customers saw on her own site. It did nothing to what a shopper saw scrolling Instagram.

This is the part almost no CSS tutorial for a broken shopify collection grid mentions. If you run any external sales channel, the CSS is a storefront-only patch. External channels see the raw source images, before any browser-side rule is applied. For a single-channel store, that gap does not exist and you are done. For a multi-channel store, the storefront fix is only half of the job, and the other half is normalizing the source images themselves - either resizing to a shared ratio, or agreeing on a supplier image spec for anything new.

We did not know this in advance. We had to be told, by an owner, that her Instagram preview was still ugly. That is the thing about a fix that works on the surface: it is not always working everywhere. In her case, the compromise was fine; she updated the CSS on the storefront and hand-normalized the twenty-odd photos that mattered most for paid social, and left the rest.

For a fuller picture of how theme code changes and app conflicts read on your live store, this piece on collection filters vanishing without warning shares part of the same diagnostic instinct.

What we learned

If the CSS you pasted did nothing, the first question is not "which rule do I need?" It is "which of my elements is that rule actually pointing at?" DevTools answers it in about ninety seconds and saves you an evening of guessing.

The related question is quieter and worth sitting with. If the fix you found on the internet was written for a version of your theme that shipped five years ago, and you have no reliable signal that it is stale, how many other "fixed" issues on your store are running on fixes that no longer touch anything? Which collection page have you not looked at, in DevTools, this month?