Your business partner opens the website on her iPhone and says the headings are cramped and a row of boxes has collapsed into one long column. On your Windows laptop in Chrome it looks exactly as designed. You are both looking at the same page, and you both think the other is mistaken.
When a WordPress site looks different in different browsers, the cause is usually ordinary, and most of the time it is not the browser’s fault at all. Before you hunt for a compatibility bug, it is worth ruling out the ordinary reasons two people see two versions of a page. Then, if a real difference remains, you can narrow it down to the browser engine and the specific feature that it handles differently.
Step one: is it really the browser?
Most “browser” complaints turn out to be something else. Check these first, because each one produces exactly the same report.
- Different screen widths. A phone and a laptop are not just different browsers, they are different layouts. Compare Chrome on a phone with Safari on the same phone before blaming Safari. If the problem appears on every phone browser, it is a mobile display problem rather than a browser one.
- A cached old version. One person may still have yesterday’s stylesheet. A private window rules this out on both sides.
- Logged in versus logged out. If you are logged in, WordPress shows the admin bar and many caching and optimisation plugins step aside for you. Visitors get the optimised page.
- Browser zoom or a larger text setting. Someone who has set their phone to large text sees bigger headings that wrap differently. That is their choice, and a good layout should cope with it.
- Extensions. Ad blockers, dark-mode extensions and translation tools change pages. Try with extensions off.
If the difference survives a private window on the same device at the same width, it is a genuine browser difference. Our separate guide on changes that do not show up on the live site deals with the caching side in more detail.
What differences are normal
Some variation between browsers is expected, and chasing it costs time without helping visitors.
- Font rendering. The same font can look slightly heavier on a Mac than on Windows because each system smooths text its own way.
- Form controls. Unstyled dropdowns, checkboxes, date pickers and file upload buttons use each browser’s own design. A date field looks quite different on an iPhone and on desktop Chrome.
- Scrollbars. Some systems show them permanently, others only while scrolling, which changes the available width by a few pixels.
None of these is a bug. A fault is when content overlaps, disappears, becomes unreadable, or something stops working in one browser.
Why a WordPress site looks different in different browsers: the real causes
There are effectively three browser engines doing the work behind the browser names you know. Chrome, Edge, Opera, Brave and Samsung Internet use Chromium’s engine. Firefox uses its own. Safari uses Apple’s WebKit, and on iPhones and iPads other browsers have generally used WebKit too, which is why Chrome on an iPhone often behaves like Safari rather than like Chrome on your laptop. So “it breaks in Safari and in Chrome on my iPhone” usually points at one cause, not two.
A newer CSS feature the browser does not support yet
Browsers add support for new layout and styling features at different times, and people do not all keep their devices updated. A theme that relies on a recent feature can look right in an up-to-date Chrome and fall apart on an older iPhone that has not had a system update in a while. Because Safari updates with the operating system, an old phone means an old Safari.
The reference for this is MDN, Mozilla’s documentation for web developers, which shows a browser compatibility table at the bottom of each CSS feature’s page: developer.mozilla.org. You do not need to read code to use it. If your developer says “this uses feature X”, you can look it up and see which browsers support it.
Vendor-specific rendering of flexible layouts
Rows of boxes, cards and columns are usually built with flexbox or grid. These are well supported now, but the browsers have historically differed in small ways: how an image inside a flexible box decides its height, how a box shrinks when its content is too long, or how gaps between items are handled on older versions. The symptom is the iPhone report from the opening: boxes stretched, squashed, or stacked when they should sit side by side.
Image formats
Speed plugins often convert images to WebP or AVIF. Current browsers handle WebP, but older versions of some browsers do not handle every newer format, and a plugin that serves the new format without a fallback leaves a blank space for those visitors. If images are missing in one browser only, check whether the image address ends in .avif or .webp and whether the speed plugin has a fallback option.
Fonts and icons loaded differently
Web fonts and icon fonts can be blocked by a browser’s privacy settings, by an extension, or by a server that does not allow the font file to be loaded from another address (a CDN, for example). The page then falls back to a system font, and icons become empty squares. Our guide on fonts and icons that go missing covers this pattern.
JavaScript that a browser handles differently
Less common now, but still seen: a script written using a feature that one browser added late, or that relies on something only Chromium-based browsers provide. A carousel, menu or form that works in Chrome and does nothing in Safari or Firefox falls into this group. The browser’s console will usually show an error that the other browser does not.
How to test fairly without owning every device
- Test the three engines. Chrome or Edge, Firefox, and Safari. If you do not have a Mac, an iPhone or iPad gives you WebKit.
- Use developer tools for widths, not for engines. Chrome’s device toolbar resizes the page to phone widths, but it is still Chrome. It will not show you a Safari-only fault.
- Write down the exact versions. On a phone, the operating system version matters most for Safari. On desktop, each browser’s About page shows its version.
- Take screenshots side by side of the same section at the same width. It removes all doubt about what differs.
- Check one page that uses a plain layout. If a simple text page looks the same everywhere and only the homepage differs, the fault is in that page’s design, not the theme as a whole.
Browser compatibility issues and page builders
Page builders generate a lot of layout code automatically, and their output depends on the settings chosen for each section. Most builders let you set different values for desktop, tablet and mobile. A compatibility report that is really a tablet report is frequently a missing tablet setting rather than a browser bug. Before treating it as a browser compatibility issue, open the builder’s responsive mode and check that section at each breakpoint.
If the layout is broken in every browser, rather than one, that is a different problem; our guide to a broken WordPress layout starts there.
Deciding which browsers you need to support
No small business site can be tested against every browser version ever released, and it does not need to be. A sensible approach is to support the current versions of the major browsers, plus the versions that your own visitors actually use. If you have Google Analytics or a similar tool installed, its technology or device reports show which browsers and operating systems your visitors arrive with. That list, not a general rule, should decide how far back you go.
If a real share of your visitors are on older iPhones, for example because your customers keep phones for years, then a layout that breaks on those devices is worth fixing properly. If one visitor in a long while uses a very old browser, a readable but plainer layout for them is a reasonable outcome. Write the decision down, so the next person who works on the site knows which browsers count.
When to stop adjusting and ask for help
If you have confirmed a real difference in one engine, the fix is usually a small CSS change with a fallback for the browsers that need it. Writing that safely means checking that the change does not upset the browsers that were already fine, which is where well-meant edits in the Customizer’s Additional CSS box often go wrong. If you would rather not risk it, our wordpress bug repair page explains how we take on this kind of fault. Send the page address, the browsers and versions that fail, and a screenshot from each.
A site does not have to look identical in every browser. It has to be readable and usable in all of them, and that is a far more reachable target.
Next in this series: WordPress Language Not Changing? Check These Settings
