Crop generated visuals for responsive layouts

Start with one master and three real placement boxes

Treat responsive cropping as a placement test, not as three independent image-generation prompts. Begin with one approved source visual and define the actual wide, square, and vertical containers in which it must appear. Record the focal subject, any detail that cannot be clipped, the intended live-copy zone, and the minimum breathing room around both. OfflineCreator Studio's current image generator exposes 16:9, 9:16, and 1:1 source ratios; those presets can provide useful starting masters, but selecting a source ratio does not prove that the image will survive every downstream container.

Build a crop matrix before editing: source file, source ratio, container ratio, focal coordinates, protected edges, and pass or fail. Use the genuine generated file in each test rather than a placeholder with a conveniently centered subject. This research did not produce or receive an authorized OfflineCreator output set, so the procedure is reproducible guidance rather than a claim that a particular generated visual passed all three formats.

Use the source-to-container mismatch as the first risk signal

Compare ratios before judging aesthetics. A recent merged GitHub pull request offers one concrete, non-generated example: a mobile team-photo box used a 4:3 frame around a 2:3 portrait source, and the author reported that `object-cover` reduced the visible photo to a middle band. The change replaced the mobile frame with 2:3 while leaving the desktop rule intact; the pull request reports checks at 390px and 1440px. This is one repository's implementation account, not a general benchmark or evidence about AI-image quality.

Two current documentation examples make the crop decision inspectable without pretending they are generated-output tests. MDN's worked art-direction example switches from `elva-800w.jpg`, a wider source, to `elva-480w-close-portrait.jpg` below 800px so the people remain legible. Cloudinary's live guitar-player example uses a face-focused 2:1 fill crop at 800px and wider, the uncropped image from 600px to 799px, and a face-focused 1:1 thumbnail below 600px. These examples demonstrate source selection and explicit ratios; neither verifies OfflineCreator output quality.

Apply the evidence narrowly. If a portrait subject must remain complete, a wide frame plus `cover` creates predictable vertical loss; if a landscape scene must fill a tall story card, the side context is at risk. Mark that mismatch in the crop matrix before moving the focal point. Changing the frame ratio, using a separate art-directed crop, or accepting letterboxing may preserve more meaning than repeatedly nudging the same image inside an incompatible box.

Choose cover, contain, and focal position deliberately

Use `object-fit: cover` when edge-to-edge fill is mandatory and clipping is acceptable. Google Chrome's responsive-image guidance states that `cover` preserves the image's aspect ratio and crops as needed; `contain` also preserves the ratio but leaves empty space when the container shape differs. That makes the choice a content decision: use `contain` when showing the complete object matters more than filling the frame, and use `cover` only after identifying what may safely leave the frame.

Set `object-position` from the protected focal point instead of accepting the centered default. Test positions such as `50% 35%` in the real component, then inspect the result at each breakpoint and at intermediate widths. A focal coordinate can rescue a modest mismatch, but it cannot reveal two opposite edges at once. If preserving a face removes a product or preserving a product removes required context, stop adjusting the coordinate and prepare a different crop.

Switch to art direction when one crop cannot carry the meaning

Use the HTML `picture` element when the mobile and desktop compositions genuinely need different crops. MDN's exact content model is zero or more `source` elements followed by one `img` element; the browser evaluates each source's `srcset`, `media`, and `type` conditions and uses the `img` when no source matches. MDN specifically identifies art direction - cropping or modifying an image for different media conditions - as a common use.

Export crops from the same approved master when possible: for example, a wide version that preserves subject and copy space, a square version that tightens peripheral detail, and a vertical version that retains the full focal path. Keep the `img` alternative text and fallback meaningful because the selected file may change while the image's page purpose should not. If the crops communicate materially different information, re-evaluate the text alternative in each placement rather than assuming one description fits every context.

Run a breakpoint crop proof before delivery

Create a small proof page using the production container rules. Include the intended 16:9, 1:1, and 9:16 boxes, plus the actual breakpoints where the component changes. For each box, render the same master with `cover`, the chosen `object-position`, and an outline showing the container boundary. Then render any art-directed alternative beside it. Review at minimum the narrowest supported viewport, the breakpoint edges, and the widest content width; a crop that works only at preset endpoints can still fail between them.

Record passes against observable criteria: focal subject fully readable, protected product geometry retained, no generated lettering partially clipped, live-copy zone still quiet, and no required context pushed outside the frame. Also include intrinsic `width` and `height` on the final `img`; web.dev notes that these dimensions let the browser reserve the correct aspect-ratio space even when responsive CSS renders the image at another size. A screenshot proof documents the placement tested, but it does not establish that every browser, localization, or future layout will match it.

Choose the next guide from the unresolved production task

Return to the creative-workflow directory if the image-generation method or deliverable is still undecided. Use the responsive-hero guide when the next task is planning a source composition with deliberate focal placement and copy space. Use the generated-text guide when lettering inside the pixels must be replaced with accessible, editable typography. This page remains responsible for testing an already generated visual against real responsive containers and deciding whether focal positioning or art-directed crops are required.

Editorial ownership boundary

This researched draft retains the route's narrow ownership because it provides source-backed real responsive-crop examples and current first-party support for 16:9, 9:16, and 1:1 source ratios. The crop examples are a conventional-photo pull request plus MDN and Cloudinary documentation, not generated OfflineCreator examples. No authorized generated crop set was available, so this page must remain a degraded-coverage draft; if editorial policy requires real generated examples rather than credible responsive-image examples, the overlap guard calls for consolidation into the workflow directory instead of promotion.

Within that boundary, this page owns source-to-container ratio comparison, focal positioning, art-directed derivative selection, breakpoint proofing, and placement-specific accessibility review. It does not claim that OfflineCreator outputs were generated during research, that one composition is consistent across separate generations, or that a crop improves engagement. Source-image planning belongs to the responsive-hero guide, and replacement of generated lettering belongs to the live-typography guide.