How to Validate AI-Generated Hero Images Before They Ship

A preflight script using ImageMagick 7 can block AI-generated hero images from shipping unless they are a single-frame 1200 × 630 WebP under a 250 KiB budget, catching mismatched exports, mislabeled formats and oversized replacements that pass review in a pull request. The workflow, which starts from a wide-composition prompt for GPT Image 2.6 on PWZ and exports via `magick` with `-resize '1200x630^'`, `-extent` and quality 82, runs the same `check-hero.sh` check locally and in CI against the file the page actually serves. The format check reads the image itself, so a PNG renamed to `hero.webp` still fails, and animated WebP files fail the single-frame comparison.

A landing page image can look fine in a pull request and still be wrong for production. The export might be 1600 × 1000 when the layout expects 1200 × 630. A file called hero.webp might still be a PNG. And a designer can replace a small draft with a much heavier export without anything in the build noticing. A preflight check can catch all three problems. The example below uses a 1200 × 630 WebP and a 250 KiB file budget for one landing page. Those values are project choices. Use the dimensions and budget your own page needs. Generate the artwork with the crop in mind For this example, imagine a landing page for a task planner. The hero image shows a notebook and a pencil, with the headline rendered by the page. If you’re creating the artwork with GPT Image 2.6 https://www.pwz.com/models/gpt-image-2-6 on PWZ, ask for a wide composition and keep the main subject away from the top and bottom edges. That gives you room to crop the image to the final aspect ratio. A starting prompt might be: A wide editorial photograph of an open notebook and pencil on a warm grey desk. Place the notebook in the right half of the frame and keep it clear of the top and bottom edges. Leave the left half quiet for a headline. Soft side lighting, no lettering or logos. Download the source image as source.png . The rest of the workflow uses ImageMagick 7 and works with any source image you have permission to use. Export the file the page will actually serve magick source.png \ -auto-orient \ -resize '1200x630^' \ -gravity center \ -extent 1200x630 \ -strip \ -quality 82 \ hero.webp The ^ tells ImageMagick to resize until both target dimensions are covered. -extent then crops the result to the requested frame. The crop is centred here, so review the result if the subject sits near an edge. Quality 82 is a starting point. A textured image can still exceed the size budget at that setting. Check the actual format, dimensions, and file size Save this as check-hero.sh : bash /usr/bin/env bash set -euo pipefail file=${1:?Usage: bash check-hero.sh path/to/hero.webp} limit=$ 250 1024 if -s "$file" ; then echo "Image is missing or empty: $file" &2 exit 1 fi bytes=$ wc -c < "$file" if bytes limit ; then echo "Image is $bytes bytes; maximum is $limit." &2 exit 1 fi actual=$ magick identify -format '%m %w %h\n' "$file" if "$actual" = "WEBP 1200 630" ; then printf 'Expected one 1200×630 WebP frame. Got:\n%s\n' "$actual" &2 exit 1 fi echo "PASS: 1200×630 WebP, $bytes bytes." Run bash check-hero.sh hero.webp locally, then run the same command in CI against the file your page will serve. The format check reads the image itself, so renaming a PNG to hero.webp still fails. The check also expects one frame. An animated WebP produces multiple lines and fails the same comparison. Preview the image in the page Open the page at its desktop and mobile breakpoints. If the component uses object-fit: cover , the browser can crop the image again inside a narrower container. Check that the notebook still reads clearly, that the headline remains legible, and that the visual still makes sense at phone size. When the crop fails, adjust the source or the component’s object-position , then review it at the same breakpoints. Once the framing works, keep the file check in CI so the next image replacement has to meet the same production requirements.