Why is there blank space around the images in my Shopify theme?

Blank space inside an image frame is almost never a broken image. The frame gets its height from your CSS and the photo gets its height from the file, and if nothing tells the photo to take the frame's height, the difference between the two shows as empty container. The rule people reach for, object-fit: cover, does not fix this on its own: with no height to fit into, cover has nothing to do and changes nothing.

Everything below is measured rather than remembered. On 6 September 2026 we read the CSS of the 20 distinct theme designs stored in our own research directory, counted every image rule in them, and then measured a page that is live on this site right now and gets it wrong in two places. The numbers, including the two defects of our own, are all here.

Which of the four image faults do I actually have?

They look similar in a screenshot and they have completely different causes. Select the image, open Computed styles, and read two values: the image's own height, and the height of the element wrapping it.

The first three are all the same underlying situation seen from different angles: a frame with a height of its own, holding an image that does not know about it.

Why does object-fit: cover not fix it by itself?

object-fit describes what a replaced element should do when its box and its content disagree about shape. If the box has no height of its own, there is no disagreement to resolve. The browser sizes the image at its intrinsic ratio, the declaration sits there doing nothing, and the frame's background shows through below the photo.

Four combinations, and only one of them works:

The pair that works is three declarations, not one:

.card__media { aspect-ratio: 4 / 5; overflow: hidden; }
.card__media img { display: block; width: 100%; height: 100%; object-fit: cover; }

We know this pattern well because we wrote it into the instructions our own generator follows, after hitting the fault repeatedly. The instruction says, in as many words, that height: 100% is the part themes forget. That did not stop it happening again.

The same bug, live on this site, measured today

The free live preview at Peg Lane has three image frames on the page. One is correct and two are not. Measured in a headless browser at a 1440px viewport on 6 September 2026:

At a 390px phone viewport the same two frames leave 85px and 152px. It is not a desktop only problem, it just scales with the frame.

The cause is visible in the served markup. The theme source writes <img class="lp-img" ... width="1100" height="880">, and the CSS rule that fills the frame is written against that class. What the preview actually serves is <img src="./assets/hero-1.png" loading="lazy">. The class was dropped somewhere in the render path, so the rule has nothing to match, and the computed object-fit falls back to its default of fill while the image keeps its own height. The declaration is in the stylesheet. It is simply not reaching the element.

That is worth knowing generally: a rule you can read in your stylesheet is not evidence that it applied. Read the value off the element, not off the file.

What aspect ratios do theme frames actually use?

Across the 20 designs we read on 6 September 2026 there are 114 fixed aspect-ratio declarations, using 24 distinct values, in 19 of the 20 designs. Only one design sizes its images without ratios at all. So the situation the pattern above describes is not an edge case, it is what nearly every theme does.

Grouped by shape that is 55 portrait, 42 landscape and 17 square. Ten of the 24 values carry a decimal, such as 4 / 3.4 and 16 / 10.5, which is a designer tuning a frame by eye to about a tenth of a unit. Those are fine as CSS. They are a problem only if you expect a photo library to match them.

How much of a photo does cover throw away?

Our bundled photography is 100 files across 12 niches at exactly three intrinsic sizes: 1408 x 768, 1024 x 1024 and 1280 x 896. Put each of those into the most common frames and object-fit: cover discards this much of the picture:

This is the honest cost of the fix. Making a wide photo fill a 4 / 5 frame means more than half of it is now outside the frame, and which half survives is decided by object-position, which defaults to the centre. If your product sits on the left of the shot, it is gone. The choice is between a frame ratio near your photography's ratio, or shooting to the frame, or setting object-position per image. There is no setting that keeps the whole photo and fills the box.

Why do my images have no width and height attributes?

Separate problem, same element, and it is the one Shopify's own tooling will tell you about. shopify theme check has a rule called ImgWidthAndHeight that flags any <img> without both attributes, because without them the browser cannot reserve space before the file arrives and the page jumps as images load.

The split in our own repository is stark, and the reason is worth reading:

Two caveats so this is not read as more than it is. The 240 are design pages, which is an intermediate artifact, and the Liquid our pipeline emits from them does set the attributes, so the shipped themes are not at 0. And the 53 out of 54 is not virtue, it is a repair: theme check flagged 33 tags across 11 of our files in July 2026 and we added the attributes then. The single remaining exception is an image built in JavaScript for a modal that opens after the page has settled, where there is no layout left to shift.

If you are writing the markup yourself, Shopify's image_tag filter sets both attributes for you from the image object, which is why it is worth using even when a plain tag would be shorter. The attributes are layout hints only. They do not fight the CSS above, because height: 100% overrides an attribute.

How do I find every unfilled image on my store at once?

Open your storefront, open the browser console, and paste this. It reports any image that is shorter than the element wrapping it.

document.querySelectorAll('img').forEach(img => {
  const box = img.getBoundingClientRect();
  if (!box.width) return;
  const frame = img.parentElement;
  const f = frame.getBoundingClientRect();
  const gap = Math.round(f.height - box.height);
  if (gap > 4) {
    console.log(gap + 'px unfilled', frame.className || frame.tagName,
      'frame ' + Math.round(f.width) + 'x' + Math.round(f.height),
      'image ' + Math.round(box.width) + 'x' + Math.round(box.height),
      'object-fit: ' + getComputedStyle(img).objectFit);
  }
});

Run against our own preview page it prints exactly two lines, the two frames in the table above, and stays quiet about the one that is correct:

130px unfilled lp-does__img frame 512x410 image 512x279 object-fit: fill
234px unfilled lp-final__img frame 514x514 image 514x280 object-fit: fill

Two things to know before you trust it. It compares each image to its immediate parent, so an image whose parent is a link that also wraps a caption will report a gap that is really just the caption. Read the class name it prints and check that the element is a media frame. And it only sees the current viewport, so run it wide and narrow, because a frame's ratio is fixed while its width is not.

What if the frame is empty rather than under filled?

A flat rectangle with no photo in it at all is a different fault, and there are three common versions.

• Nothing was uploaded. Sections built around an image_picker setting render a placeholder until a merchant picks a file in the theme editor. A newly installed theme showing beige boxes where the photography goes is usually this, and it is not damage. On one of our own paid renders it was 4 out of 4 image fields.
• The file 404s. A section referencing an asset the theme does not actually ship gets a broken image, and if the theme also has an onerror handler that hides the tag, you get a clean empty box with no clue in the interface. We shipped exactly that once by writing .png where the files were .svg: it was on 150 themes at once, and it was invisible until a structural check compared every image reference against the files in the ZIP. The Network tab is where this shows up, as a red row.
• The tag never became a tag. If a filter in the image line is not supported by whatever is rendering the page, the URL can come through as plain text inside the media container, which then looks like a styled empty box. Viewing source is the fastest way to tell an empty box from a missing tag.

If whole sections rather than single images are blank, it is a different question again, and we wrote it up separately in why a Shopify homepage is blank after installing a theme.

The order to check things in

1. Right click the empty area and choose Inspect. Confirm there is an <img> element there at all.
2. Read the image's rendered height and its parent's rendered height. If the parent is taller, this is the fill problem.
3. Read the computed object-fit on the image, not the declaration in your stylesheet. If it says fill, your rule is not matching the element, and the usual reason is a class that is not on the tag.
4. Add height: 100% alongside the existing width: 100% and object-fit: cover, in a rule you have confirmed matches.
5. Look at what the crop now cuts. If the subject is out of frame, change the frame ratio or set object-position, rather than reverting the fill.
6. Run the console snippet at a wide and a narrow window, and check the Network tab for 404s on image files.

We check this pair automatically on every theme we generate, because our own output produced the fault first and our own preview page still carries two instances of it. If you would rather start from a theme where the image frames are already filled, the free theme gallery has live previews you can inspect yourself before downloading anything, and the sideways scroll write up covers the other half of the box model problems that show up on a phone. The same habit of reading the computed value rather than the declaration also settles the other quiet theme fault, which is a color setting that saves and changes nothing.