Why Does My Website Look Different on Mobile Than Desktop?

First compare the same published URL in a private window, then on another phone. Note the browser, viewport width, text-size setting and whether Desktop Website is enabled. A difference on one phone is a useful clue, not proof that the site is fine: it can reveal a browser-specific layout or input problem.

If you already know the page is broken and want repairs, not a diagnosis, our guide to making a website mobile friendly lists seven fixes in priority order.

Start with the symptom

Why does my website look different on mobile than desktop? Seven layers to check

Of the seven layers below, three change the page on purpose. The other four are where faults hide, and a fault in the first can stop the media queries in the second from ever firing.

1. The viewport

The viewport meta tag tells a mobile browser to lay the page out at the real screen width. Without it the browser uses a wider virtual window and shrinks the result: MDN's example is a 640px screen rendered in a virtual viewport of 980px. Media queries written for phone widths never fire, because as far as the page knows, the window is never narrow.

Having the tag proves little, since the 2025 Web Almanac found it on 95.2% of mobile pages. What matters is what it says, and whether there is only one: a fixed width such as width=1024, a user-scalable=no that blocks pinch zoom wherever the browser obeys it, or a second tag added through custom head code. Grigora's free meta viewport checker prints the string it found and flags all three. Re-run it after a theme change or new head code, since either can add a tag of its own.

View the saved viewport check at full size.

A phone's address bar expands and retracts as you scroll, but 100vh is sized as if the bar were hidden, so a hero set to 100vh bleeds out of the viewport on load. Use dvh, which follows the bar, or svh, which assumes it is showing. Both work from Chrome 108, Firefox 101 and Safari 15.4.

2. Media queries and breakpoints

This is the layer people mean by responsive design. Below a breakpoint, columns become rows and the navigation folds behind an icon. None of it is a bug: it is a decision somebody wrote down in CSS, and your job is to check it was the one you wanted.

3. Container queries

Since 14 February 2023, size container queries have worked in every major browser engine. They let a block respond to the size of its own container rather than the viewport, so one card can be two columns in the main area and one in a sidebar on the same screen. If a block changes and no breakpoint explains it, search the CSS for @container. If there is none, skip this layer.

4. Images

A phone can receive a different image file. With srcset and sizes the browser chooses a candidate for the displayed width and pixel density; that is not always the smallest file. With the picture element you can serve a different crop, which MDN calls the art direction problem: a wide shot with a person in the middle shrinks that person to almost nothing on a phone. A tighter hero crop on mobile can be intentional.

The blurry logo is a different problem. devicePixelRatio is how many physical pixels span one CSS pixel, counted across: 1 on a classic 96 DPI display, 2 on a Retina screen, and often more than 2 on a phone, per MDN. A phone 393 CSS pixels wide at a ratio of 3 paints 1,179 real pixels across, so a logo exported at the 200 pixels it occupies is stretched over 600. Export it at 600, or use an SVG. Photos work out differently, because a file sized for the wider desktop column usually covers the phone as well. Our guide to what size blog post images should be works through the numbers.

5. Text and fonts

Some mobile browsers run a text inflation algorithm for pages never built for phones. When a block of text spans the full width of the screen, the browser enlarges it without changing the layout around it. So an old desktop site does not look uniformly tiny on a phone. It looks lopsided: some paragraphs blown up, the rest left small.

Web fonts change type on phones too, just later. With font-display: swap the fallback font paints first and the web font replaces it on arrival, which web.dev warns can cause layout shifts. On mobile data you can watch the headings reflow. On office wifi the font has usually arrived before you look, which is why this passes for a phone-only bug.

6. Touch input and dark mode

The hover media feature describes the primary input mechanism. A phone with touch as its primary input commonly reports hover: none: it cannot hover conveniently, even if a long press emulates it. Provide a button or other explicit tap and keyboard interaction for a dropdown; an attached mouse or hybrid device can report a different input capability.

Dark mode is the one people forget. prefers-color-scheme reads the light or dark setting in the operating system or browser, and has worked across browsers since January 2020. If your theme ships a dark variant, a phone set to dark shows colors you may never have seen. If it does not, a phone can still recolor it: Samsung Internet's dark mode applies its own color changes to pages without one, and its engineers note that logos and icons can merge into the darker background.

7. Caching and delivery

A responsive page can still arrive with an old stylesheet, cached HTML or a different signed-in state. Compare the same URL and published version before changing CSS. A private window helps separate cookies and local state; it does not bypass a CDN cache. Some systems also keep device variants: Cloudflare APO can cache separate mobile, tablet and desktop copies by User-Agent. Check which cache actually serves the old asset, then invalidate the affected content through your normal publishing process.

Is it normal for a website to look different on mobile?

Yes. The test is whether anyone loses something, not whether the layout moved. These differences are working as intended:

• Columns stacked into one.
• Navigation behind a menu icon.
• A tighter crop of the hero, or a different image file altogether.
• A smaller headline and tighter spacing.
• A decorative image hidden.
• A wide table scrolling inside its own box.

These are actually broken:

• The page scrolls sideways, or a white strip runs down one edge.
• Text that needs pinch-zoom to read.
• Elements overlapping.
• A button trapped under a sticky bar.
• A hero that overflows on load and fits only after you scroll.
• Content that is on desktop but missing or different on mobile, such as a price or a call to action.

Keep the substantive content and actions available on the phone. Google's mobile-first indexing guidance allows a different mobile design, including accessible accordions and tabs, but asks for equivalent primary content, descriptive alt text and structured data. Content that requires a user interaction just to be loaded can be missed by the crawler.

Measure loading speed separately from layout. The same page can perform differently on a phone because its hardware, connection and viewport differ. The Largest Contentful Paint target is 2.5 seconds or less at the 75th percentile of visits, segmented into mobile and desktop. A screenshot can reveal a broken layout, but it cannot measure that field-performance result.

What screen width should you design for on mobile?

There is no single phone width. The 393 CSS-pixel phone and 1,440 CSS-pixel laptop in the diagram are examples, not standard device categories. Start with the widths in your own analytics, include a narrow 320 CSS-pixel check, and resize between presets. Foldables, split-screen windows, browser zoom and larger text can expose a failure that one named phone preset misses.

Choose breakpoints where your content stops fitting. web.dev recommends content-based breakpoints rather than specific brands or device classes. For horizontally written pages, WCAG 2.2 Reflow requires content to remain available at a width equivalent to 320 CSS pixels without two-dimensional page scrolling. Content that needs a two-dimensional layout, such as a data table or map, has an exception; keep its scrolling within that component.

How to see what your website looks like on mobile

Run these on your own URL, in order. Each step gets closer to what a real visitor sees.

For a direct browser check, open Chrome DevTools, enable the device toolbar and choose Responsive. Move slowly through the width where the problem appears, then open the same URL on an actual phone. Chrome documents device mode as an approximation; it does not replace a real device's keyboard, touch input or CPU.

1. Read the viewport tag. Run the checker above on your live URL. A typical responsive page uses width=device-width, initial-scale=1 with zoom allowed; investigate a fixed width, duplicate tag or restrictive zoom setting. Other valid viewport options can be present.
2. Check the HTML signals. The free Mobile-Friendly Test Lite reads source HTML for viewport and explicit inline size warnings. It does not render the page or calculate a mobile-friendliness score, and it cannot measure actual tap-target spacing or external CSS. Use its findings to choose a browser check.
3. Look at two or three phone sizes. The free Mobile Preview Simulator frames your live page at iPhone, Pixel and Galaxy sizes, plus foldables and tablets. It cannot load a site that blocks iframing, and it does not simulate touch.
4. Capture both versions. The free website screenshot generator has presets at Mobile 390 by 844 and Desktop 1440 by 900. Capture the same page at each preset and lay the two side by side.
5. See what Google sees. In Search Console, run URL Inspection, then Test live URL, then View tested page. A screenshot of the rendered page appears only in a live test, alongside the HTML and console output.
6. Finish on a real phone, on mobile data. Open the menu, tap a button, start the form, turn the phone sideways. No simulator tells you the submit button sits under the keyboard.

View the saved desktop and phone captures at full size.

It looks wrong on my phone but fine on everyone else's

When one device disagrees, preserve that failing setup rather than dismissing it. Compare the same URL, account state, browser version, orientation and text settings, then try these checks.

• Request Desktop Website is still on. Safari on iPhone keeps it in the page menu as the way to see what the webpage looks like on a desktop computer. It is easy to tap once and forget.
• An older cached asset or account state. Try a private window and compare the published version. If the old version persists there too, inspect the site/CDN cache rather than assuming the phone is responsible.
• An in-app browser. Open the same link in the phone's normal browser as well as inside the app. A difference can expose navigation, login or layout behavior specific to that browser environment.
• A content blocker stripping an element the layout was built around.
• Page Zoom above 100% in Safari's page menu, or browser zoom on the laptop you are comparing against.

Test in Safari and Chrome where they represent your visitors, and keep the failing browser version in your notes. Start with forms: check that input text is readable, the focused field stays visible, and the keyboard does not cover the submit button. A 16 CSS-pixel input font is a useful starting point, not a universal browser guarantee. Preserve pinch zoom and test larger text as well.

Why your page title looks different in Google on mobile

Same page, same title tag, shorter title on the phone. That one is not your site: Google says the title link is truncated as needed, typically to fit the device width. The free SERP preview tool trims at 60 characters for desktop and 55 for mobile, a fair guide rather than Google's exact width.

If the words differ as well as the length, Google has rewritten the title from another source, such as your main heading, and that can happen on any device. It passes over titles that are half-empty, out of date or boilerplate, so the fix is a specific title and one clear main heading, part of the HTML tags worth keeping in a blog post.

How to change the mobile layout in Grigora

A builder takes the first layer off your hands and part of the fourth. Classic Grigora pages publish with the standard viewport tag and pinch-to-zoom left on, settings you make in Tablet View and Mobile View publish as responsive CSS, the header menu folds into an icon on phones, and photos you upload in the editor become AVIF files with phone-sized copies. Sites made with the AI builder start from a layout with the same viewport tag, and you ask the AI Editor for any layout change.

The rest is yours. In the editor's own labels:

1. Switch to Mobile View. The phone preview control turns the canvas into a 360px phone. Settings that can differ by device, such as direction and text size, then change for phones only.
2. Stack the columns. Multi-column sections stay side by side on phones until you select the section, open Layout, then Direction, and choose Rows.
3. Type a phone text size every time, even when the box shows a number. Left blank, the box may show the tablet value while the published phone page uses the desktop one.
4. Turn Lazy load off on the hero image. Images lazy-load by default, the hero included, which delays the first thing a phone visitor sees.
5. Hide decoration, not content. Right-click a block, then Hide on, then Hide on Mobile.
6. Republish. Nothing is live until you do.

Start by removing fixed-width assumptions and checking the failing section. Many pages can be repaired in their existing layout. If the theme or builder prevents those changes, assess a rebuild; our guide to updating a website explains how to plan that work.

Grigora's AI website builder can draft a responsive starting layout. Preview it at phone width, check the actual content and test the important actions before publishing. The trial runs for 14 days with no card needed.

Mobile versus desktop display FAQs