Job frontend-responsive-layout-breaks-one-page · revised 11 October 2026
Fix layout that breaks on phones or tablets for one page
Up to five named layout defects on one page are gone at four agreed screen widths, with before and after screenshots and an automated screenshot check you can keep.
You might be seeing
- The page scrolls sideways on a phone, or content is cut off at the right edge
- Buttons or text overlap, or a menu or button cannot be tapped at some widths
- A full-height section is hidden behind the browser toolbar on a phone
No passwords, keys, card details or admin invites needed to start.
What usually happened
The page has layout rules that fail at certain screen widths or on mobile browser behaviour: a fixed width that is wider than the screen, a flexible box that will not shrink below its longest word, a width set to the full window that includes the scroll bar, or a full-height section sized without allowing for browser toolbars. The job fixes up to five named defects on one page, and adds a screenshot check so they stay fixed.
Who it’s for: An agency, founder or product owner whose page looks right on a laptop but has a defect on a phone or tablet: text running off the screen, overlapping buttons, a menu that cannot be opened, or a sideways scroll bar.
Usually starts when: A redesign, a new component, a plugin or content change, or a new device size exposed the defect, and customers or staff are working around it.
The result: At four agreed screen widths (including 320 CSS pixels) the page has none of the named defects, shows no sideways scrolling and keeps every agreed element visible and usable. You receive before and after screenshots, the fix, and an automated screenshot check for the same widths.
Check whether this job fits
These questions check whether this is a bounded layout repair. They need no access or code.
Checks you can run yourself
Find the element that is too wide
In a desktop browser, open the page, switch to the device view at 320 pixels wide and look for a horizontal scroll bar. In the developer tools, hover over elements in the Elements panel from the top down.
Look for: The first element whose box extends past the right edge of the screen, and whether it holds a long word or address, a table, an image or a full-width element.
What you get
- A pull request with the fixes and a note naming the cause of each defect
- Before and after screenshots for each defect at each affected width
- The automated screenshot check and its stored reference images
- Reversal steps and any limits found
Included
- One page or one shared template, with up to five named layout defects listed before work starts
- Four agreed screen widths, with the narrowest at 320 CSS pixels, in one agreed browser engine, with one other checked by hand
- Find the style or markup rule behind each defect and fix it with the smallest change
- Add an automated screenshot comparison for the four widths so a later change that brings a defect back is caught
- Re-test the page and its nearest neighbours that share the same styles
Not included
- A redesign, new components or a new visual style
- Fixing pages other than the named one, beyond shared styles it uses
- Testing on every real device: we use agreed browser sizes and one engine, plus one other by hand
- Content changes, new images or copy
- Slow loading, which is a measurement job, or accessibility audits, which have their own job
- Production deployment, which stays with your team
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
At each of the four agreed widths, including 320 CSS pixels, none of the named defects is present and the page does not scroll sideways.
Evidence: Before and after screenshots for every defect at every affected width and a recorded scroll-width measurement for each width.
Every agreed element is still visible and every agreed interaction (menu opening, button tapping, form field focusing) works at each width.
Evidence: A checklist result for each element and interaction at each width.
The new automated screenshot check passes at all four widths on the fixed page and fails when one of the defect rules is put back.
Evidence: The passing run, and the failing run after temporarily reintroducing one defect, with both outputs.
The diff contains no secret, removes no content and leaves the neighbouring pages' screenshots within the agreed tolerance.
Evidence: The changed-file list, a secret scan and the neighbour comparison.
Sign-off. You or your authorised maintainer review the screenshots, open the page on one phone yourself, sign off in writing and merge. Payment follows sign-off.
If it fails. If any named defect remains at an agreed width, you do not pay for this fixed scope. If a defect cannot be fixed without a design change, we explain what we found and stop. Wider work needs a new written agreement.
When it fits, and when we stop
It fits when
- You can list the defects with the width or device where each shows, with a screenshot if you can
- The page can run in a staging copy or from source we can inspect through an agreed route
- The styles and markup can be changed through code you control
- An authorised maintainer on your side reviews and merges the change
We stop and tell you if
- The defects come from a closed tool or theme whose styles you cannot edit
- The page needs real user data to show the defect and cannot run with test data
- More than five defects, or defects that need the design to change, so a quote or a project is more suitable
What could go wrong
Before merge, closing the pull request leaves the page unchanged. After merge, your maintainer can revert the commit. The screenshot check can be removed on its own without affecting the fixes.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A defect is hidden by clipping the overflowing content instead of fixing its cause. | Acceptance requires every agreed element to be visible and usable at each width, and the reviewer checks for clipping rules. |
| A fix to shared styles changes other pages. | The nearest neighbouring pages that share the styles are screenshot-checked before and after. |
| Screenshot checks differ between machines and fail for no reason. | Reference images are generated in the same environment the check runs in, and tolerances are set and documented. |
An independent reviewer compares the before and after screenshots at every agreed width, checks that nothing was hidden to hide a defect and checks the neighbouring pages. Your maintainer reviews and merges.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- The W3C explains the reflow requirement (content usable without scrolling in two dimensions at a width equivalent to 320 CSS pixels, with an exception for parts such as data tables, which should sit in their own scrollable container), which a developer can use as a test width. www.w3.org
- MDN explains why a flexible item will not shrink below its content width and how to allow it, which is the cause of many sideways-scroll defects. developer.mozilla.org
Questions
Do you test on my actual phone?
We test at agreed browser widths in one engine and one other browser by hand. We cannot promise every device. You should open the page on one real phone before you sign off.
What if the page needs a new design on mobile?
That is a different job. This one fixes named defects and keeps the design as it is meant to look.
Why add a screenshot check?
So the defect cannot quietly come back after the next content or style change. It is yours to keep or delete.
Is this the same as a bug fix with a regression test?
It is similar in spirit, but a layout defect is proved by screenshots and measurements at agreed widths, not by a unit test.
Send an enquiry
Send us
- The page address and a list of the defects, with the device or screen width where each appears and a screenshot if you have one
- The technology the page is built with and whether you can change it
- Which browsers and devices your visitors use most
- Do not send credentials, source code, customer data or an access invitation in the first enquiry
Later, once you agree
- The page source through an agreed company-controlled route, with a branch for the pull request
- A staging address or run instructions with test data that holds no customer information
- The agreed list of defects and widths, signed off by you
- The name of the person who reviews and merges
You own the site, its design and its content. We work on a branch or staging copy through a company-controlled identity, never a personal login, with test data. Your team deploys.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “frontend-responsive-layout-breaks-one-page” as the subject.