How to fix responsive layouts in an AI-built app

Find the constraint that breaks the page

Open the page at a narrow viewport and inspect the first region that extends beyond the screen. Common causes include a fixed-width panel, a grid whose minimum column widths exceed the container, an unbroken URL, or an image without a width constraint.

A wide table or code sample may deserve its own scrollable container. The entire page usually should not scroll horizontally. Avoid applying overflow-x: hidden to the body as the first fix: it can make controls disappear without solving the layout problem.

Use the following browser-console diagnostic to find candidate elements. It is a starting point, not a verdict: intentional offscreen menus and decorative elements can also appear in this list.

[...document.querySelectorAll('body *')].filter((el) => {
  const rect = el.getBoundingClientRect();
  return rect.right > document.documentElement.clientWidth
    || rect.left < 0;
});

Replace a rigid three-column layout

A grid defined as repeat(3, 320px) needs at least 960 pixels before gaps are included. That can be appropriate for a horizontally scrolling board, but it fails as a general responsive content grid. This original example lets cards choose their column count from the space available.

The inner min(100%, 16rem) allows a single column to fit containers narrower than the preferred minimum. min-width: 0 allows a child to shrink, and overflow-wrap handles unusually long content. Resize the page to see the example below move between columns.

.projects {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(min(100%, 16rem), 1fr));
  gap: 1rem;
}
.projects > * { min-width: 0; overflow-wrap: anywhere; }
img { max-width: 100%; height: auto; }

Let content determine the breakpoint

Drag the viewport gradually instead of testing only a phone preset and a desktop preset. Watch where navigation stops fitting, labels wrap awkwardly or the main action becomes hard to reach. Those transitions tell you where a breakpoint or a simpler layout is useful.

Do not shrink all text to keep a desktop composition on a phone. Stack related sections, allow headings to wrap, preserve control sizes and avoid locking content into fixed heights. Test at increased text size as well as at different viewport widths.

Run a repeatable responsive check

For a first pass, use 320, 390, 768 and 1440 CSS pixels. These are useful sample widths, not a complete list of devices. Add intermediate widths where the layout changes, and check at least one real phone if available.

Test forms after errors appear, navigation after it opens and cards after replacing the sample title with something much longer. Desktop emulation cannot prove every touch, keyboard or browser behavior. Keep a short record of the widths and states you actually verified.

• No unintended page-level horizontal scroll.
• Inputs and primary actions remain reachable.
• Images keep their proportions.
• Long words, validation messages and translated text can wrap.
• Keyboard focus is not clipped by containers.

Further reading

• MDN: responsive design