Make Horizontal Overflow Structurally Impossible on Mobile
Four CSS guards that stop a single long token or grid track from blowing your mobile layout sideways, verified by measuring rects not page scroll.
Open your app on a 390-pixel phone, swipe the screen sideways, and watch the whole layout drift. A band of empty space appears on the right, content slides under the bezel, and a heading that read fine in your editor now cuts off mid-word. Somewhere on that page, one element is wider than the viewport, and it is dragging everything with it.
The cause is almost always boring. A customer ID like cus_9f2a8b7c6d5e, a config token, a pasted URL, an email address, a CSS grid track that sized itself to its widest child. Any one of them, with no spaces to break on, forces a container wider than 390 pixels, and a single overflowing element on a mobile screen makes the page feel broken. The fix is not to chase each one with a screenshot after a user reports it. The fix is to make horizontal overflow structurally impossible, so this class of bug cannot happen by construction. Four CSS guards do that, and we ship all four on the first commit of every app we build.
Why this keeps happening
Long unbreakable strings are not an edge case. They are a certainty. Users paste them, your AI features generate them, your database hands you IDs that look like pack:abc_def_ghi. The moment any of those lands in a flex item or a grid cell with no wrapping rule, the browser does the only thing it can: it makes the box wide enough to hold the longest token, and that width propagates up through the layout until something exceeds the viewport.
The trap is that the symptom and the cause live in different places. The overflow is generated in a deeply nested card, but the scroll appears on the whole page. So teams reach for a blanket fix on the body and think they are done. They are not, and the reasons why are worth understanding.
Guard 1: clip the real scroll container, not just the body
The instinct is body { overflow-x: hidden }. Do not do that. hidden risks breaking position: sticky on descendants, because it creates a scroll container, and it is the lazy mask that hides the symptom while leaving the cause. Use clip, which forbids scrolling without creating a scroll container, so sticky headers and fixed backgrounds keep working.
But clip on body alone silently fails in a case that is more common than it sounds. When the actual scroll container is <html> rather than <body>, the overflow propagates up past the clipped body to the root, and the page scrolls sideways anyway. This happens any time a smooth-scroll library like Lenis is active, because those libraries scroll the document root and leave html overflow visible. It also happens when a transformed descendant escapes the body's clip, the same way a Next.js page can render unstyled only in Safari when one browser handles a CSS feature differently than the rest. Browser-specific behavior is where these structural bugs hide.
The reliable fix is to clip contextually, at the content regions where overflow is actually generated, not only on body:
body, main, footer { overflow-x: clip; }
Clipping main, footer, and individual section elements contains the overflow at the content edge while leaving vertical scroll and sticky chrome untouched. A concrete trigger we hit repeatedly: a scroll-reveal animation that slides rows in from off-canvas with transform: translateX(54px). That off-screen transform is real horizontal overflow, and it is exactly the kind of motion you would also gate behind respecting users who get sick from motion so it never runs when it should not. Body-only clip will not contain it under Lenis. Clip the content regions and the row still slides in from the now-clipped viewport edge, which is exactly the effect you wanted.
Guard 2: overflow-wrap anywhere, not break-words
This is the guard that costs teams the most time because the wrong choice looks almost right. Tailwind's break-words maps to overflow-wrap: break-word, which breaks a long word visually but does not reduce a flex or grid item's min-content size below its longest token. So the token still forces the container wide, and you are left wondering why your wrap rule did nothing.
Only overflow-wrap: anywhere shrinks the min-content size so the item can actually fit inside its box. That is the property you want.
.prose, .chat-bubble, .card-body { overflow-wrap: anywhere; }
overflow-wrap inherits, so set it on shared containers and every descendant text node is covered cheaply. Apply it anywhere variable text lands: questions, options, IDs, room names, role labels, audit details, code chips, chat replies. This matters especially for LLM output rendered as markdown, where a model can emit a long unbroken token mid-stream. Pair it with min-w-0 on any flex or grid child that holds such text, because flex and grid items default to a min-width that refuses to shrink below their content.
Guard 3: tame the grid track that grows to its content
CSS Grid has a silent killer. A grid track defaults to auto, and an auto track sizes to its widest content's max-content size. One long token in one cell makes that column grow to eight hundred pixels, which drags the entire grid and every other row sharing that column past the viewport. Worse, if you applied Guard 1, the page clip now hides the scroll, so an automated check that only reads scrollWidth reports everything is fine while the content is actually clipped and unreadable.
The fix is to pin single-column stage and shell grids to the container instead of their content:
.stage { display: grid; grid-template-columns: minmax(0, 1fr); }
minmax(0, 1fr) lets the track shrink to zero and the content wrap inside it, rather than ballooning to max-content. Add min-w-0 to grid items that hold variable text. Any display: grid rendering dynamic content is a suspect, and this one line per grid removes a whole category of layout blowout.
Guard 4: cap fixed-pixel children to the container
The last guard catches the white-gap-on-the-right bug, and it is the one teams hit most often because it looks like a different problem each time. Any element given a fixed pixel width will overflow its container the moment the container is narrower than that value. A device-preview iframe locked to 390px inside a 358-pixel mobile canvas. An embed, a media frame, a fixed-width card. The symptom is unmistakable: content shifts left, clips on the left edge, and a band of empty space appears on the right, with horizontal scroll to match.
The fix is always to cap the fixed width to the container, the same attention to the thumb-sized realities of a phone that stops you losing taps to bad thumb zones and tiny targets:
.preview { max-width: min(390px, 100%); }
Or in inline styles, style={{ maxWidth: \min(${fixedWidth}, 100%)` }}. Never ship a bare width: 390px` on anything that can land in a narrower box. On mobile this is non-negotiable: no horizontal scroll, and nothing overflows to create a right-side gap, ever.
Verify by measuring rects, not page scroll
The most important thing to know about verifying this work is that document.scrollWidth === clientWidth is a lie. Guard 1 makes that comparison pass while content is still clipped and broken. To actually verify, you have to measure element rectangles.
Seed a worst-case token into every dynamic field in your data, something like asdfasd_asdfasdf_asdfsa_asdfasdf_asdfasdf, not just eyeball it. Render the page at 390 pixels, walk every screen and every overlay (menus, modals, chat panels, settings tabs), and assert that no element's right edge exceeds the viewport. This worst-case-input mindset is the same one that drives a PWA that feels native on iOS despite Safari's limits: you design for the hostile case, not the happy one. Iterate the DOM, check each element's bounding rect, and flag anything whose right exceeds clientWidth, excluding elements that legitimately live inside an overflow-x: auto scroll region. That measurement catches what page-scroll checks miss.
This is the kind of defense that belongs in the build, not in a bug ticket. It is the same enforce-it-at-the-gate instinct behind a performance budget your team will not quietly break: a structural rule that fails loudly the moment someone crosses it beats a guideline nobody remembers. The same anticipate-the-worst-case discipline shows up across the work we do, from the websites we ship to the security audits where we look for exactly these structural gaps before an attacker or a confused layout finds them first.
The four lines that end it
Put these in your global stylesheet and shared components on day one. Clip the content regions, not just the body, so overflow cannot escape to the root. Use overflow-wrap: anywhere so long tokens shrink their box instead of widening it. Pin grid tracks with minmax(0, 1fr) so one cell cannot balloon the row. Cap every fixed-pixel child to min(width, 100%) so it never exceeds its parent. Then verify by measuring rects at 390 pixels with a hostile string in every field.
Do that, and the next time someone pastes a 50-character ID with no spaces, it wraps quietly inside its box, and your layout never moves. The bug does not get fixed one screenshot at a time. It stops being possible.