In short
A responsive site is supposed to look different on mobile: columns stack, navigation collapses, images shrink and type resizes. It looks wrong on mobile when something was fixed at a desktop width, when the viewport meta tag is missing so the phone renders the desktop layout tiny, when an element overflows and creates horizontal scrolling, when hover-dependent features have no touch equivalent, or when a browser-specific quirk was never tested. Diagnose with the browser's device mode, confirm on a real phone, and fix the layout rule rather than hiding the symptom.
The difference that is supposed to be there
A responsive website is one design that rearranges itself for the screen it is on. On a phone, three columns become one, a horizontal menu becomes an icon, a large hero shrinks, type gets slightly smaller and lines get shorter, and sidebars move below the content. None of that is a bug. It is the site adapting, and a site that did not do it would be unreadable on a phone.
So the first question is: does it look different, or does it look broken? Broken has a specific set of symptoms.
Symptom 1: the whole desktop site, very small
The page looks exactly like the desktop version shrunk to fit a phone, with tiny text that needs pinch-zooming. This means the page has no viewport meta tag, or has one that is wrong. Without <meta name="viewport" content="width=device-width, initial-scale=1"> in the head, the phone assumes the page was designed for a 980-pixel screen and scales it down. One line fixes it, and it is the single most common cause on older or hand-built sites.
Symptom 2: horizontal scrolling
The page is wider than the screen; you can swipe sideways and see empty space or content hanging off the edge. Something has a fixed width larger than the phone's screen: an image with width="1200", a table, a div with a pixel width, an embedded map or video, a long unbroken string such as a URL, or padding and margins that add up to more than 100%.
Find it by opening the browser's developer tools in device mode and inspecting elements until one shows a width greater than the viewport; or add a temporary outline to every element with CSS. Fix it at the source: max-width: 100% on images and embeds, overflow-x: auto on tables so they scroll within their container, overflow-wrap: anywhere on long strings, and box-sizing: border-box so padding is included in widths. Adding overflow-x: hidden to the body hides the symptom while leaving content cut off; it is the last resort, not the fix.
Symptom 3: things overlapping or squashed
Columns that were meant to stack are jammed side by side at a quarter width each; text overlaps an image; a button is half off the card. The layout has a breakpoint missing, or a component was positioned absolutely for one screen size. This is a CSS problem specific to the element, and the fix is a media query or a switch to a layout that flows naturally, such as flexbox with wrapping or grid with auto-fit. Our piece on CSS grid versus flexbox covers which suits which case.
Symptom 4: it works on your phone and not theirs
iOS Safari and Android Chrome differ, and both differ from desktop browsers. Common culprits: viewport height units (100vh) behaving differently under Safari's toolbars; form controls rendering with the operating system's own styling; older Android browsers lacking a CSS feature; and iOS zooming into any input with text smaller than 16 pixels. Testing on one phone is not testing on mobile. At minimum, test on a recent iPhone and a mid-range Android, and use the browser's device mode for the rest.
Symptom 5: it relies on a mouse
Menus that open on hover, tooltips that appear on hover, image galleries that need a hover to show controls. Phones have no hover. Anything that only works on hover is invisible or unusable on touch. The fix is to make every hover interaction also work on tap, or to provide a visible control on small screens. This is also an accessibility fix, since keyboard users have the same problem.
Symptom 6: images are wrong
A hero image cropped so the subject is out of frame, a logo blown up to fill the width, a background image showing an irrelevant corner. Images that were composed for a wide screen need a different crop or focal point for a tall one. object-fit: cover with object-position set to the subject fixes most; a separate mobile crop via the picture element fixes the rest.
How to test properly
- Device mode in the browser. Chrome and Firefox developer tools simulate phone widths and let you inspect any element. This finds layout problems in seconds.
- A real phone. Emulation misses browser-specific behaviour, touch, and performance. Open the site on an actual phone over mobile data. Do this before every launch.
- Several widths. Not just "mobile": 360, 390, 430, 768 and 1024 pixels cover the common phones and tablets, and the page should be usable at every width in between, not only at the breakpoints.
- Rotate it. Landscape phones are wide and short and expose height-based assumptions.
- Slow it down. Throttle the connection in device mode; a layout that jumps as images load looks broken even if the final state is fine.
When the difference is a design decision
Sometimes the site looks different on mobile because someone chose to hide a section, simplify a component, or move the call to action, and the choice was right. The question to ask about any difference is whether the mobile visitor can do what they came to do as easily as the desktop visitor. If yes, the difference is design. If they cannot find the phone number, read the pricing, or submit the form, it is a defect, whatever the CSS says. Testing with a real task on a real phone is the check that catches it, and it is part of every pre-launch review we run.
If a site is misbehaving on phones and the cause is not obvious from device mode, book a call; most of these are found in fifteen minutes.
Common questions
Why is my website so small on mobile?
The page is missing the viewport meta tag, so the phone assumes it was designed for a wide screen and scales the whole desktop layout down. Add <meta name="viewport" content="width=device-width, initial-scale=1"> to the head of every page and the browser will render at the phone's real width.
Why does my website scroll sideways on mobile?
An element is wider than the screen: usually an image or embed with a fixed width, a table, a long unbroken URL, or padding that pushes a container past 100%. Inspect elements in the browser's device mode to find the one exceeding the viewport, then constrain it with max-width: 100%, overflow: auto for tables, or overflow-wrap for long strings.
Why does my site look fine on my phone but broken on someone else's?
Because phones and their browsers differ. iOS Safari and Android Chrome handle viewport height, form controls, font sizes and some CSS features differently, and older devices lack newer features. Test on at least one recent iPhone and one mid-range Android, and use browser device mode for other widths.
How do I test how my website looks on mobile?
Use the device mode in Chrome or Firefox developer tools to simulate common phone widths and inspect elements, then confirm on a real phone over mobile data, since emulation misses browser quirks, touch behaviour and performance. Check several widths, rotate to landscape, and try to complete a real task such as submitting a form.
Should a website look the same on mobile and desktop?
No. A responsive site is meant to rearrange for the screen: columns stack, navigation collapses, images and type resize. The test is not whether it looks identical but whether a mobile visitor can do everything a desktop visitor can, as easily. Differences that preserve that are design; differences that block it are defects.
