Bubble mobile responsive not working: breakpoints and layout fixes
On Bubble, mobile layouts usually fail for three reasons: the mobile breakpoint is still at 320px while most phones are wider, so mobile conditions never fire; conditions test that the page width equals a value instead of being at or below it; or elements and groups have fixed or minimum widths wider than the screen. Raise the breakpoint to where your layout actually breaks, use at-or-below conditions, and let containers shrink.
What you'll see
On a phone the page is wider than the screen and scrolls sideways, a four-column repeating group squashes into unreadable strips, buttons overlap text, or the menu runs off the edge. The mobile changes you set in the Responsive tab look right in the editor but never appear on a real phone.
Why it happens
1. The mobile breakpoint is too narrow
A 320px breakpoint only applies to very small screens. Phones around 375 to 430px wide are treated as larger than mobile, so the layout you designed for phones is skipped. Bubble forum members point to this as the usual reason mobile settings seem ignored.
2. Conditions use equals instead of at-or-below
A condition like Current page width = 320 is true at exactly one width. It should be Current page width is less than or equal to your breakpoint so it covers every phone.
3. Fixed and minimum widths are larger than the screen
A group with a fixed width of 1100px, or a minimum width of 600px, cannot shrink, so it pushes the page sideways. Fixed-position elements and wide images do the same.
How to fix it
- Temporarily put a text element on the page showing Current page width, open the live page on your phone, and note the number. Delete the element when you are done.
- Open the Responsive tab and look at the breakpoints. Change the mobile breakpoint to the width where your layout starts to break, often somewhere between 480 and 768px, or add a custom breakpoint and name it.
- Go through conditionals that change layout and replace equals checks with Current page width is less than or equal to the breakpoint. Using a named breakpoint means changing its value later updates every condition at once.
- Select each wide group and check its width settings. Replace fixed widths with a maximum width, remove minimum widths that exceed a phone screen, and let column containers stack by switching them to a column layout on mobile.
- For repeating groups, set a condition that reduces the number of columns on mobile, and check that cells do not have a fixed width larger than the screen allows.
- Preview at several widths in the editor’s Responsive tab, then test the live page on a real phone in portrait and landscape.
How to check it's fixed
- At 375, 390 and 414px wide the page does not scroll sideways and nothing overlaps.
- Buttons and links are easy to tap and text is readable without zooming on a real phone.
What a QAlaunch scan shows for this
- Horizontal overflow at 390px, where the page is wider than the phone screen.
- Overlapping, clipped or hidden elements in the phone screenshot, from the visual review.
- Tap targets that are too small or too close together, and text that is too small to read.
See exactly what a full report contains in the sample report.
Frequently asked questions
Which breakpoint should I use for mobile?
There is no single right number. Drag the editor width down until your layout starts to look wrong and set the breakpoint there. It does not need to match any specific phone.
My app uses the legacy responsive engine. Does this apply?
The breakpoint advice is for the current responsive engine. Pages still on the legacy engine behave differently; Bubble’s manual covers converting them, and converting is usually worth it for mobile work.
Why does a button work on desktop but not on mobile?
Often another element overlaps it on narrow screens, even an invisible one, and catches the tap. Look for groups that sit on top of each other at phone width.
Do I need a separate mobile page in Bubble?
Rarely. One page with containers that stack and a few breakpoint conditions is easier to maintain than two copies that drift apart. Build a separate page only when the mobile experience is genuinely different, such as a native-style app view.
Rather have a QA engineer test it by hand?
If this is a site you're launching or handing to a client, I'll go through it by hand, including the Bubble-specific issues a scan can't reach, like logged-in flows.
- Up to 10 key pages tested by hand, not a scan
- Every flow a customer uses: forms, sign-up, checkout, booking
- Real mobile and desktop browsers
- A written report in plain language, with screenshots
- A 15-minute call to walk you through it
- 10 years of professional QA experience
Tell me about your site and I'll reply personally, usually the same day.
No payment now. I'll confirm scope and price first.
Related fixes
More for Bubble: all Bubble fixes
Written by Waqas Ahmad, QA engineer with 10 years of professional testing experience. Last checked October 26, 2026.
Sources: Bubble forum: mobile responsiveness is not working · Bubble forum: custom responsive breakpoints · Bubble forum: buttons work on desktop but not mobile