Image dimensions belong in your content model

You already know what sizes you need

Every image on your site serves a context: hero banners, thumbnail grids, inline illustrations, author headshots. Each context has implied constraints—aspect ratio, minimum resolution, display width. If you're letting a CMS or frontend script resize images reactively, you're encoding those decisions in implementation details instead of your content model. That's a maintenance problem dressed up as flexibility.

Document the dimensions first. Not as CSS variables or image processing parameters, but as explicit fields in your content type definition. A "Featured Image" field should specify 1200×630 pixels, not "large enough for social sharing." A "Thumbnail" should be 400×400, not "square-ish." Precision eliminates the gap between what editors upload and what the template expects.

Aspect ratio is a content decision

When you accept arbitrary image dimensions, you're deferring a layout decision to crop algorithms or object-fit heuristics. Algorithmic cropping will clip faces, slice through text overlays, or center on empty space. Object-fit will letterbox or distort. Both outcomes mean you didn't decide what matters in the frame.

Define aspect ratio as a content constraint. If your card grid needs 16:9 images, the upload interface should enforce or guide toward 16:9. If author headshots are 1:1, make that explicit before someone uploads a landscape photo and wonders why it looks wrong. The content model is where you declare "this image is always this shape," not the place where you hope responsive images will figure it out.

Minimum dimensions prevent quality problems

A 300-pixel-wide JPEG might look acceptable as a thumbnail. Stretched to hero size, it's a blurry embarrassment. If your template can display an image at 1600 pixels wide, your content model should reject uploads smaller than that threshold. Validation at upload time prevents quality problems at render time.

Set minimums per field, not per site. A thumbnail field can accept 400×400. A hero field requires 1600×900. Different contexts, different rules. When you enforce dimensions in field definitions, editors know what's expected before they hunt for an image.

Exact dimensions simplify templates

Templates that assume fixed image dimensions are easier to write, faster to render, and less fragile than templates that accommodate any ratio. If you know a card thumbnail is always 400×400, you can predefine its layout container, skip object-fit gymnastics, and avoid cumulative layout shift. Predictable dimensions let you write <img width="400" height="400"> with confidence.

Responsive images still work. Serve a 400×400 image at 1x, an 800×800 version at 2x. The aspect ratio remains constant; only resolution scales. That's simpler than generating five crops at different ratios and hoping srcset picks the right one.

Document the output, then enforce the input

Start by auditing where images appear. List each context: hero, thumbnail, inline, gallery, author bio. For each, note the display width, aspect ratio, and minimum acceptable resolution. That's your spec.

Then encode it. If your CMS supports dimension validation, use it. If not, add help text that states the requirement and shows an example: "Upload a 1200×630 PNG or JPEG. Minimum file size: 150 KB." Explicit constraints beat implied guidelines every time.

Image dimensions aren't a nice-to-have. They're structural requirements that prevent layout breaks, quality degradation, and editorial confusion. Define them in your content model before the next image goes into the CMS.