Why Does My Website Look Broken on iPhone Safari? Causes and Fixes

At Talha Aslan and team, we hear this complaint constantly: "It looks fine on my laptop, but my client's iPhone shows a mess." The key detail is simple. Every browser on iPhone, Chrome included, runs on WebKit. So opening Chrome on an iPhone does not give you the same result as Chrome on Android.

This guide focuses on one question only. Why does the site break on iPhone Safari, and in what order should you fix it? For broader mobile problems, see our post on mobile-only SEO issues. Here we stay with Safari-specific behavior.

Is the problem really Safari, or something else?

Start with diagnosis. "Broken on iPhone" often covers three separate problems: a true WebKit difference, a responsive bug at narrow widths, or a stale cached file. Therefore you narrow it down first.

1. Open the same page on an Android phone and in your desktop browser's device mode.
2. If only the iPhone shows the bug, test Safari first and then a second iPhone browser.
3. When both iPhone browsers show it, the cause is almost certainly WebKit.
4. If Android also breaks at narrow widths, the cause is your breakpoints, not Safari.
5. Reopen the page in a private tab to rule out old cached files.

If the issue turns out to be width related, our guide on choosing responsive design breakpoints is the better place to start. On the other hand, if only iPhones misbehave, work through the causes below in order.

Which symptom points to which cause?

Naming the symptom correctly cuts repair time dramatically. For example, "the bottom button is missing" usually points to a height unit. Meanwhile, "the page zoomed in by itself" usually points to the font size of a form field. The table below summarizes the matches we see most often.

When you send this to your developer, include the iPhone model and the iOS version. In short, a screenshot plus device details beats hours of guessing.

Why does 100vh overflow on iPhone Safari?

This is the most common cause by far. Many sites size the opening hero to 100 percent of the viewport height. However, mobile browsers show and hide the address bar and toolbar as you scroll. According to web.dev's explanation of viewport units, the vh unit does not update when those toolbars change.

As a result, when the page first loads with the toolbars visible, a 100vh section extends past the visible area. The "Get a quote" or "Call now" button at the bottom sits off screen. Only after the visitor scrolls and the toolbar retracts does the section fit. Also, the shift feels like the content is twitching.

The effect stands out on iPhone Safari because its toolbars move a lot during scrolling. Android browsers can show similar behavior. Still, most teams test on desktop, so the first report usually comes from an iPhone user.

How do dvh, svh and lvh fix the height problem?

The new viewport units exist for exactly this case. web.dev describes three options:

• svh (small viewport): 1 percent of the visible area with toolbars expanded. It stays stable.
• lvh (large viewport): 1 percent of the visible area with toolbars retracted. It also stays stable.
• dvh (dynamic viewport): switches between the two as the toolbars expand or retract.

In practice, svh is usually the safest choice for a hero section. That is because it keeps the main button on screen at first load and does not recalculate while scrolling. dvh fills the visible area at every moment. However, content resizes as the toolbar moves, so animation-heavy sections can feel jittery.

For older browsers, our team always writes a vh value first and the new unit second. That way, a browser that ignores the new unit falls back to the old one. Check current support on MDN or caniuse, since browser versions change and we do not rely on exact version numbers here.

Why does the page zoom in when you tap a form field?

The second most common complaint goes like this. A visitor taps the name field on a contact form and the page suddenly zooms in. After they submit, the screen stays zoomed and a horizontal scroll appears. On iPhone Safari, this happens on input, select and textarea fields with a small font size.

Safari does this to make small text readable. But if the designer left the form in a small, elegant font, every tap triggers the zoom. The fix we use in the field is to keep form text large enough on mobile. Developers commonly use 16 pixels or more. Treat that number as a field-tested starting point, not an official threshold, and verify it on your own device.

One frequent mistake is disabling user zoom in the viewport tag. That breaks accessibility, because visitors with low vision can no longer enlarge text. So fix the font size instead of locking zoom. Also note that the text-size-adjust property on MDN controls text inflation, a separate mechanism, and it does not stop form zoom.

Why do fixed headers and bottom bars jump or drift?

A sticky "Call" or "WhatsApp" bar at the bottom, a fixed header at the top, or a cookie banner causes the most trouble on iPhone Safari. When the toolbar shrinks during scrolling, the bottom bar floats for a moment and then snaps back. Meanwhile, the on-screen keyboard can push fixed elements to unexpected positions.

The root cause is the area that fixed positioning measures against. With the keyboard open, the visual viewport shrinks, but the layout viewport stays the same. Consequently, an element pinned to the bottom edge can hide behind the keyboard or hang in the middle of the screen.

Our practical checklist:

• Does the bottom bar hide when the keyboard opens on pages with forms?
• Does the header height leave content tucked underneath it?
• Does the sticky header sit inside a container with overflow hidden? If so, sticky will not work at all.
• Do the cookie banner and the bottom bar overlap?
• Does the bottom bar account for the safe area at the bottom edge?

Most of these are design decisions. In other words, before any code change, ask whether that element truly needs to stay on screen.

Why does the notch cut off content at the edges?

iPhones with a notch or Dynamic Island have rounded corners, a camera area at the top and a home indicator at the bottom. According to WebKit's official guide, the default viewport-fit value is auto, and Safari insets content within the safe area.

Trouble starts when a designer sets viewport-fit to cover for an edge-to-edge look. Content then fills the whole screen. However, the rounded corners and sensor housing can hide part of a text block or a button. In landscape, the menu icon may even sit behind the camera.

WebKit's recommended fix uses the env() function with safe-area-inset-top, safe-area-inset-right, safe-area-inset-bottom and safe-area-inset-left as padding. In addition, you can pair them with max() to set a minimum margin, so the padding never drops to zero on any device. Put simply, if you use cover, add safe area padding. If you do not, the default behavior usually works fine.

Why do numbers turn into blue links on iPhone?

Long digit strings such as prices, order numbers, tax IDs or dates sometimes appear blue and underlined on iPhone. Tap one and the phone offers to call it. Apple's Safari meta tag reference describes this directly: Safari on iOS turns text formatted like a phone number into a call link by default.

Sometimes this helps you, and sometimes it ruins the design. For example, a product code shown in blue hurts both branding and trust. The fix has two steps. First, turn off phone detection with the format-detection meta tag. Then mark your real phone numbers with tel links on purpose.

That way you decide which numbers are callable, and you can measure call clicks. For how to build that button and track calls, our sister post on click-to-call buttons and call tracking goes into detail, so we will not repeat it here.

Why do images not show up on iPhone?

An image that loads on Android but shows an empty box on iPhone usually comes down to format support. Modern formats like WebP and AVIF shrink file size. However, support for them arrived later in older iOS versions. If the visitor has not updated their phone, the image simply never appears.

So whenever you use a modern format, always offer a fallback. With the picture element, list AVIF first, then WebP, and finally JPEG or PNG. The browser then picks the first format it understands. Also confirm that your server sends the correct content type, because a wrong type can trip up Safari.

Check current support on caniuse, since the picture changes as iOS evolves. Example scenario: an online store uploads category covers only as AVIF, and shoppers on older iPhones see blank tiles. Adding a fallback format solves it, and the lost conversions stop.

How do unsupported CSS features break the layout?

Some CSS features reach Chrome before Safari. A developer tries a new feature in desktop Chrome and sees no problem. However, if the iPhone user's iOS version does not recognize that feature, the browser ignores the rule entirely. The grid collapses into one column, spacing disappears, or the background blur never shows.

The groups we run into most often:

• Gap support differences in flex layouts on older versions.
• Newer color functions and color mixing.
• Container queries and relatively new selectors such as has().
• Effects like backdrop blur that may still need a prefix.
• Date and time inputs, which look very different in Safari.

The approach stays the same. First, write a safe base rule. Then add the new feature inside a feature query with @supports. That way, browsers that lack the feature still get a clean, simple layout. The compatibility table at the bottom of every MDN feature page lists Safari and Safari on iOS in separate rows, so check there.

Why does horizontal scrolling appear only on iPhone?

If the page slides slightly to the side, something overflows the screen. Some Android browsers can mask that overflow. On iPhone Safari, though, the whole page wobbles sideways, which gets annoying fast when you scroll with your thumb.

Common sources include sections sized with viewport width units that ignore scrollbar space. Long unbroken links or email addresses also cause it. So do card rows that refuse to shrink, and embedded map or video frames. Moreover, the input zoom described above can leave a horizontal scroll behind.

To diagnose it, find the overflowing element in developer tools and fix its width. Adding overflow hidden to a wrapper works as a quick patch. However, that rule can break a sticky header. So finding the actual overflowing element always gives a healthier result.

How do iPads and older iPhones change the picture?

The iPhone Safari problem does not stop at phones. On iPad, Safari requests the desktop version of many sites by default. Therefore, the rules you wrote for tablet widths may never kick in, and the menu arrives in desktop layout with small links that are hard to tap.

On older iPhones, two factors stand out. First, if the user has not updated iOS, new CSS features and image formats may lack support. Second, small-screen models are very narrow, so two-column cards that look fine on large screens overflow there.

We recommend keeping three profiles in your test plan:

• A current iPhone with a notch or Dynamic Island on the latest iOS.
• A smaller iPhone running an iOS version a few releases behind.
• An iPad with default settings.

This trio makes a simple starter set. Still, check your own visitor profile in your analytics device report, so you set testing priority based on data.

Does dark mode or text size affect how the site looks?

Some complaints come from system settings rather than the browser itself. For example, if the iPhone runs in dark mode and your site does not declare a color scheme, form fields, scrollbars or the date picker may appear in unexpected dark colors. You end up with a dark gray input box on a white background, and the design looks broken.

Similarly, if the user increased text size in accessibility settings, labels overflow buttons with a fixed height. That is not a bug. Instead, it shows the design lacks flexibility. Giving buttons padding instead of a fixed height works better.

In short, note whether the device was in dark mode and what text size it used when you took the screenshot. Then your developer can reproduce the issue under the same conditions.

Why do fonts and icons look different on iPhone?

Fonts and icons create another frequent gap. For example, if your custom font fails to load, Safari falls back to the system font. Line heights change and headings wrap onto two lines. Menu buttons may shift too, because the text takes up more room.

Icons drawn with emoji or special characters take on Apple's own emoji look. In addition, Safari applies its built-in styling to form buttons and select boxes. If the designer did not reset that styling, buttons arrive with rounded corners and shadows.

Check these questions:

• Does the font file load on iPhone, or do you see the system font?
• Do menu and button labels sit inside fixed-width boxes?
• Did the designer reset native styling on form buttons?
• Are icons SVG files, or characters that vary by device?

None of these alone makes a site unusable. That said, they hurt brand consistency and leave visitors with an impression of sloppiness, so handle them in the polish round.

How do you test iPhone Safari without a Mac?

Not everyone has a Mac on their desk, and that does not mean you cannot test. One rule holds, though. No browser on Windows or Android reproduces WebKit behavior exactly. Your desktop browser's device mode only mimics screen size; it does not swap the engine.

Conceptually, your options are:

1. Borrow a real iPhone. Two devices on different iOS versions are ideal.
2. Consider cloud-based real device testing services. They stream real remote iPhones into your browser.
3. Try desktop testing tools built on the WebKit engine. Still, make the final call on a real device.
4. Ask the user directly for a screenshot or screen recording, plus their iOS version.
5. When you can access a Mac, connect the phone by cable and inspect it live with Safari's Web Inspector.

For a general mobile layout scan, use our mobile-friendly test tool and our guide to running a mobile-friendly test. These catch layout issues. For Safari-specific differences, however, you still need the real device steps above.

In what order should you fix the issues?

Trying to fix everything at once creates new bugs. So our team starts with whatever hurts the visitor's conversion path the most. This order works on most business sites:

1. Hero height: if the main button is off screen, fix that first.
2. Form zoom: if the contact or quote form becomes hard to use, that comes second.
3. Fixed bottom bar and header: if call and WhatsApp buttons drift, handle them third.
4. Image formats: if product or service images appear blank.
5. Notch and edge padding: if content gets clipped in landscape.
6. Auto-linked phone numbers and minor CSS gaps: a final polish round.

After each step, retest on the same iPhone in a private tab. Also, if you use a caching plugin or a CDN, purge it. Otherwise you will not see the fix and may chase the wrong cause.

What if you use a theme or a site builder?

With ready-made themes, part of the problem comes from the theme's own code. For example, if the theme author locked the hero to 100vh, your options shrink. First, install the latest theme version, because many themes fix these bugs in later releases.

If an update does not help, add targeted fixes through the custom CSS area. However, theme updates can overwrite them. So keep changes in a child theme or a separate stylesheet. Drag-and-drop site builders often restrict code access entirely. In that case, contact the platform's support with your device details.

We covered the limits of builders like Google Sites in is Google Sites good enough for a business website. If you cannot touch your own code, fixing Safari issues for good gets much harder.

When does it make sense to bring in a professional?

You can handle most of the steps above at the diagnosis level yourself. However, the repair stage requires knowing the theme structure, the caching layer and how to test across iOS versions. For example, changing a height unit can fix one page while breaking an animation on another.

If the problem goes beyond a few pages, meaning the theme never accounted for Safari, reviewing the structure costs less than patching bug by bug. If you are planning a new site with professional web design, ask in writing during the proposal stage which devices and browsers the team will test on.

Our approach is to run the same checklist on real iPhones and Android devices before handover. That way, the gap between "fine on my screen" and "broken on the client's phone" closes before launch day.

What information should you send your developer?

"The site is broken on iPhone" tells a developer almost nothing. If they cannot reproduce the bug, they cannot fix it. So enrich your report with these details:

• The full page URL and the section where the problem appears.
• The iPhone model and iOS version, found under General in the Settings app.
• The browser used, and whether the bug also shows in a private tab.
• Whether the phone was in portrait or landscape.
• A screenshot or a short screen recording.
• When you first noticed it, and whether anyone updated the site just before.

Also list which pages repeat the problem, because a single-page bug and a sitewide bug come from different sources. This list shortens diagnosis considerably. Example scenario: if a user sees zoom only on the contact page, the developer goes straight to the form styles instead of reviewing the whole theme.

Do Safari bugs hurt SEO and conversions?

Google usually evaluates your pages with an Android-based crawler for mobile-first indexing. Therefore, a Safari-only layout bug may not show up as a direct ranking signal. That does not make it harmless.

If iPhone visitors cannot see the button, fight a zooming form or stare at a blank product image, they leave. That lowers conversions and wastes your ad budget. Moreover, a large share of Google Ads and Meta traffic arrives on mobile devices, so the iPhone experience directly affects campaign efficiency.

In short, treat Safari compatibility as an item on your conversion checklist, not just your SEO checklist. For pre-launch QA, we suggest adding an iPhone Safari row to the list in our website pre-launch testing checklist.

Conclusion: how do you close out an iPhone Safari bug?

An iPhone Safari problem is rarely one big bug. It is usually several small differences stacked together. First, confirm the cause is really WebKit. Next, match the symptom to its cause using the table. Then fix the issues in order of conversion impact. Finally, retest on a real device, in a private tab, with caches cleared.

If you want a site that behaves the same on every device, with testing done before handover and fixes that last, take a look at our web design services. At Talha Aslan and team, we run the same checklist on real iPhones and Android phones, and we step in on the structural parts you cannot solve alone.