Square In, Wide Out: Cropping AI Images for Real Page Layouts

The gap between generating an image and shipping one is a shape problem, and it is almost never in the plan.

A generator returns a square. As of September 2026 SEOpix produces images at 1024x1024 through DALL-E 3, and most tools in this space are similarly constrained to a small set of ratios. Meanwhile the page wants a 16:9 hero, the share card wants roughly 1.91:1, the card grid wants a square, and someone will eventually ask for a tall version for a phone-first layout.

Four shapes, one image. The cropping is where good generations go to die.

Crop inward, never outward

The rule that governs everything else: removing pixels is safe, inventing them is not.

A square generation can yield a 16:9 crop, a 4:5 crop and a square, because each of those fits inside the frame you have. A 16:9 generation cannot yield a 4:5 crop without either severe side-cropping or extending the frame with generated fill, which introduces content the original composition never accounted for.

So the practical order is: identify the tallest and the widest crops you need, generate something that contains both, and cut down. In the common case where the tool gives you a square, you are already holding the most flexible shape available.

Surface	Target ratio	From a 1024 square	Watch for
In-content image	16:9 or 3:2	1024x576 / 1024x683	Comfortable; plenty of sites stop here
Full-bleed hero	16:9 or wider	1024x576	Thin on large displays — plan the source
Social share card	~1.91:1 (1200x630)	1024x536, then scale	Needs its own crop, not the hero's
Card / grid thumbnail	1:1	1024x1024	Free — this is the native shape
Vertical / mobile feature	4:5 or 9:16	819x1024 / 576x1024	Only possible from a square or taller

The row that catches people is the hero. A 1024x576 crop is fine inside a content column and marginal as a full-width banner on a wide monitor, where it will be stretched beyond its native resolution. Decide which of those you are doing before you generate, not after the design review.

Prompt for the crop, not just the picture

If the crop set is known in advance, the prompt can protect it. This is the cheapest intervention available and almost nobody uses it.

Ask for a wider shot than you think you need. "Wide shot", "environmental", "room for the subject to breathe" all push composition away from a tight frame-filling subject. A portrait that fills the square has nowhere to go when you cut 44% of the height.

Place the subject deliberately off-centre. A subject in the middle third survives every crop. A subject at the top of the frame disappears from a centred 16:9 cut.

Leave negative space where text will land. If the hero carries a headline, prompt for an uncluttered area on the side the text occupies. Generating a busy image and then hunting for somewhere to put the words is the wrong order.

Keep the horizon low or high, not centred. A centred horizon is the first thing to look wrong after cropping.

These are composition instructions rather than style instructions, and they compose cleanly with everything else you are asking for — the broader craft of writing prompts that produce usable rather than merely impressive output is covered in prompting for photorealistic images that actually work on a page.

Think in safe areas

Borrow the discipline from broadcast. Overlay your crop set on the square and identify the region that is inside all of them. That region is your safe area, and the subject belongs in it.

For a typical set — square, 16:9, 1.91:1, 4:5 — the safe area is a fairly modest central rectangle. Anything important outside it will be missing from at least one surface. Once you have seen this drawn out once, prompting for it becomes automatic, and you stop producing generations that only work in the shape they were born in.

This matters more than it sounds because the crops are not equally visible. The share card is the one people notice when it is wrong, since a clipped face on a link preview is conspicuous in a way that a slightly tight in-content image is not. Share cards also follow their own conventions rather than the page's, which is why they are treated separately in Open Graph images versus search images.

Crops are not responsive variants

This distinction causes real bugs, and the two mechanisms look superficially similar.

Responsive variants are the same framing at different pixel dimensions. A phone gets an 800-pixel-wide version of the identical composition. This is srcset and sizes, it is a bandwidth optimisation, and the browser picks from candidates that differ only in scale. The mechanics are covered in srcset and sizes.

Art direction is different framing for different contexts — a wide crop on desktop, a tighter square on mobile so the subject stays legible on a narrow screen. This requires <picture> with source elements and media conditions, because the browser cannot infer that you want a different composition rather than a different size.

Putting differently-framed images into a srcset is the failure mode. The browser treats them as interchangeable and chooses on pixel density and viewport, so visitors get compositions semi-randomly. If the framing differs, it is art direction and it needs <picture>.

Let the machine crop, but tell it where to look

Cropping every variant by hand does not survive contact with a real content pipeline. Most CDNs and several CMS platforms will crop on the fly from a single source — request the same file at a different ratio and you get it back cropped to fit.

The default behaviour is a centre crop, which is exactly why automated cropping has a bad reputation. Centre-cropping a composition whose subject sits off-centre produces precisely the decapitated hero everyone has seen.

Two mechanisms fix it, and both are worth knowing:

Focal points. Most image services let you store a point of interest per image — expressed as coordinates or a named region — and crop outward from it rather than from the geometric centre. Setting one focal point per image once means every future crop, at every ratio anyone invents later, frames correctly without further intervention. This is the highest-leverage five seconds in the whole workflow.

Content-aware cropping. Some services detect faces or salient regions automatically. It works well on obvious subjects and unpredictably on ambiguous ones — a wide environmental shot with no clear focal subject is exactly the case where automatic detection picks something you did not intend. Treat it as a sensible default rather than a guarantee, and spot-check the surfaces that matter.

The practical setup for generated imagery is therefore: generate wide with the subject deliberately placed, set a focal point at that subject, and let the pipeline produce the ratios. You keep one master, the crops stay correct, and adding a new surface later costs nothing.

One caveat on automated pipelines: a crop served through a transform URL is a different URL from the original, and consistency about which version is the canonical one on the page matters — otherwise you drift into having several addresses for what is nominally one image.

Encode once, at the end

Cropping is an editing operation and every lossy save compounds. Crop a JPEG, save it, crop it again, save it again, and you have applied lossy compression three times to the same pixels.

Keep the generated file as a lossless master. Perform every crop from that master. Produce the delivery formats in one final pass. The quality settings for that pass, and how far you can push them before artefacts show, are covered in compression quality settings, and the format choice per surface in WebP versus AVIF versus JPEG.

One caveat specific to generated imagery: AI output often contains smooth gradients and soft bokeh that compress well, alongside occasional fine texture that does not. Judge the encode on the actual image rather than a site-wide default, particularly for anything with text or a diagram-like element — where the tradeoffs differ enough that screenshots and diagrams warrant their own settings.

Name the variants so future-you can tell them apart

Four crops of one image is four files, and four files with meaningless names is a maintenance problem within a month.

Use a consistent suffix that says what the variant is for: boiler-repair-fort-worth-16x9.webp, -og.webp, -square.webp. The base name carries the descriptive content and the suffix carries the shape, which keeps the SEO image filename doing its job while making the set self-documenting.

One discipline to attach to this: crops are variants of one image, not additional images. Publishing five crops of a single generation across five pages, presented as distinct imagery, is precisely the pattern that creates near-duplicate image clutter — and at scale it is worse than having fewer images, because it dilutes which file should represent anything. One canonical image per subject, cropped per surface, referenced deliberately.

The short version

• Decide the crop set before generating.
• Generate at the shape that contains all of them — usually the square.
• Prompt wide, with the subject off-centre and space where text goes.
• Keep the subject inside the intersection of every crop.
• Crop from a lossless master; encode once at the end.
• Use <picture> for different framings, srcset for different sizes.
• Suffix the variants; keep one canonical image per subject.

None of this is difficult. It is simply a step that tends to be discovered at the moment a designer asks why the hero is cut off, which is late.

---

SEOpix generates at 1024x1024 with the filename, alt text and EXIF metadata already written in, so the crop pass is the only work left before publishing. See the feature list, compare plans from $0 to $99/month, or start on the free tier.