How To Create A Landing Page That Works On Safari And Every Other Browser

The short version: A landing page that only works in Chrome is not a working landing page, because Safari renders things differently on almost every point that matters (viewport height, form inputs, sticky elements, tracking pixels), and if you have not tested on an actual iPhone you have not tested it at all. Fix the handful of known Safari quirks below before launch, test on a real device, and stop blaming your ad targeting when the real problem is a broken button on iOS.

If you want to go deeper on this: facebook page looks black or broken.

Why Safari breaks pages that look perfect in Chrome

Chrome, Edge, and most Android browsers all run on the same engine, Chromium. Safari does not. It runs on WebKit, and Apple updates it on its own schedule, supports CSS features late (sometimes years late), and applies privacy restrictions that Chrome does not bother with. That means a landing page you built and tested only on your work laptop in Chrome can look and behave completely differently the moment someone opens it on an iPhone.

And a lot of people will open it on an iPhone. In the UK, Safari accounts for over half of mobile browsing once you count every iPhone user, because Apple forces every browser app on iOS, including Chrome and Firefox for iPhone, to use WebKit underneath. So when you think you are testing "Safari" versus "everything else," you are testing WebKit versus everything else, and WebKit is what most of your mobile audience is stuck with whether they chose Safari or not.

The specific bugs to check before you launch

These are the ones I see break landing pages on a client's site or my own, again and again. Not theoretical edge cases, actual things that stop people converting.

• The 100vh problem. On mobile Safari, height: 100vh includes the space behind the address bar, so your full-height hero section gets cut off or your sticky footer sits underneath the browser chrome. Use 100dvh (dynamic viewport height) instead, with a fallback of a fixed pixel height for older browsers.
• Input font size under 16px. If a form field has a font-size smaller than 16px, iOS Safari auto-zooms in when someone taps it, and on a lot of pages that zoom never resets, so the visitor is left staring at a zoomed-in form they cannot easily fill in or submit. Set form inputs to 16px minimum, always.
• Sticky elements need the prefix. Safari has needed -webkit-sticky alongside plain sticky for years. Miss it and your sticky CTA bar just scrolls away with the page.
• Flexbox gap. Safari did not support gap in flex containers until version 14.1 (2021). If any of your traffic is on an older iPad still limping along on an unsupported iOS version, your columns will overlap or sit flush with no spacing.
• Autofill styling. Safari forces its own yellow-ish background on autofilled fields and largely ignores your CSS. The fix is a -webkit-box-shadow: 0 0 0 1000px white inset trick on the input, which is ugly but works.
• Video autoplay. A background video that plays fine in Chrome will simply not play in Safari unless the video tag has both muted and playsinline attributes. Forget one of them and your hero video is a static black box on every iPhone.
• Date pickers. An input type="date" renders as a native, unstyled Safari picker that looks nothing like the rest of your form and cannot be restyled with normal CSS. If your webinar sign-up form asks for a date, budget time for this or use a JavaScript date library instead of the native input.

The tracking problem nobody mentions in the "make it responsive" checklists

Here is the part most landing page guides skip entirely: even a page that looks flawless on Safari can still quietly break your conversion tracking. Safari's Intelligent Tracking Prevention (ITP) blocks or limits third-party cookies far more aggressively than Chrome does, and it can cap the lifespan of first-party cookies set by JavaScript to as little as seven days. That means your Meta pixel, if you are relying on it for retargeting or attribution, will under-report Safari conversions, sometimes badly. If you have ever looked at your ad platform's numbers and thought "these people converted but the pixel didn't fire," Safari is very often the reason. I wrote a full walkthrough on setting up conversion tracking for Meta ad campaigns that covers how to set this up with server-side tracking (Conversions API) precisely because relying on the browser pixel alone means you are flying blind on every iPhone visitor.

A real example: the webinar page that "worked fine"

A coaching client of mine ran a leadership webinar last year and built the registration page herself using a popular page builder, tested it on her laptop in Chrome, checked it looked fine on her phone (an Android), and launched a Facebook ad campaign pointing straight at it. Two weeks in, the cost per registration had crept up to nearly three times what she was expecting, and she assumed the targeting or the ad copy was the problem, so she rewrote the ad three times.

The actual problem was the page. The sticky "Reserve my seat" button sat fixed at the bottom of the screen on Android and Chrome, but on iPhone Safari it overlapped with the browser's own bottom toolbar, so the last twenty pixels of the button, including the tap target, were unreachable on a lot of iPhone models. She lost that battle to something she never even opened, because she never tested on an actual iPhone. We fixed the padding and the sticky positioning, retested on three different iOS versions, and cost per registration dropped back down within days without touching the ad at all. If she had been running a webinar and needed a fuller platform comparison at the same time, our roundup of webinar software tools covers which platforms handle their own registration pages more reliably across browsers so this is one less thing to build from scratch.

The uncomfortable bit: Chrome DevTools "device mode" is not real cross-browser testing

Most people, including a fair few agencies, will tell you they have tested a page "on mobile" because they opened Chrome DevTools, clicked the little phone icon, and resized the window to look like an iPhone. That tells you almost nothing about Safari. DevTools' device emulation is still running the Chromium rendering engine underneath, it just changes the viewport size. It will not reproduce a single one of the WebKit-specific bugs above, not the vh issue, not the flexbox gap, not the autofill styling, none of it. Agencies rarely say this out loud because it means extra billable hours testing on real devices, and clients rarely ask because they assume "responsive" and "cross-browser" are the same job. They are not. Responsive means the layout resizes. Cross-browser means it works once it resizes. The only honest way to check is to open the live page on a real Safari browser, ideally a real iPhone and a real Mac, not an emulator pretending to be one.

A step-by-step process that catches these before launch

1. Build with dvh, not vh, from the start. Retrofitting this after the layout is finished takes far longer than writing it correctly the first time.
2. Set every form input to 16px font-size minimum. Add this to your base stylesheet so nobody forgets it on a new form.
3. Add vendor prefixes or run autoprefixer. Tools like PostCSS's autoprefixer plugin handle the -webkit- versions automatically so you do not have to remember them by hand.
4. Test the form's autofill behaviour on an actual iPhone with saved autofill data turned on, not a fresh incognito window.
5. Check every video and animation. Confirm the muted and playsinline attributes are on any autoplaying video before you leave staging.
6. Load the page in Safari's Web Inspector (connect an iPhone to a Mac via cable and use Safari's Develop menu) to see genuine console errors, not Chrome's version of them.
7. Check tracking with the pixel helper on Safari specifically, ideally with a fresh iPhone or private browsing session, before you trust your ad platform's numbers.
8. Use a real device lab or a service like BrowserStack if you do not own an iPhone or a Mac, so you are testing genuine Safari rendering rather than a guess.
9. Test on at least two iOS versions, because a fair number of users are still one or two versions behind the newest release, and older WebKit versions have their own gaps in support.
10. Do this before launch, not after the ad spend has already started. Every day a broken page runs live ads is money spent finding out what you should have found for free.

If you are building the page yourself

Not every marketer wants to write raw CSS, and you do not have to. Most modern page builders have improved their cross-browser handling considerably in the last couple of years, but they are not all equal, and some still ship themes that lean on unsupported CSS or unoptimised video embeds. Our comparison of landing page builders for marketers flags which ones handle mobile rendering and Safari quirks out of the box, so you are not starting from a template that already has the vh bug baked in.

If you would rather have an AI tool audit an existing page for you, tools like Claude's browser extension can now open a live page and flag obvious rendering or accessibility issues while you watch, which is a useful first pass before you bring in a developer. I wrote about testing that on my own site in Week 8 of my rebuild diary, where letting an AI loose on my own pages caught a handful of things I had missed simply because I was too close to the work.

Why this matters more in 2026 than it did five years ago

Apple has kept tightening ITP with every iOS release, mobile commerce keeps growing as a share of total traffic, and the gap between "looks fine on my laptop" and "works for every visitor" keeps widening rather than closing. If you are trying to grow a business through 2026, a landing page that quietly fails a third of your visitors before they even see your offer is not a small technical detail, it is a direct hit to your revenue that most people never diagnose because the symptoms look exactly like a bad ad or weak copy.

If you need a page for one offer without touching your main site, my roundup of the best landing page builders compares the options.

I've also listed the website glitches that lose you visitors. If you want more engagement, interactive calculators on your website are worth testing.

Frequently asked questions

Why does my landing page look fine on my phone but broken for other people?

Your phone's browser and your visitors' browsers are probably not the same. If you are on Android and testing in Chrome, you are not seeing what a large share of iPhone visitors see in Safari, because Safari renders sticky elements, viewport height, and form inputs differently. Always test on a real iPhone with Safari before you trust that a page works.

Do I need to build separate versions of a page for Safari and Chrome?

No, one page with a few Safari-specific fixes is enough. You need the dvh viewport unit instead of vh, 16px minimum font-size on form inputs, the webkit prefix on sticky positioning, and muted plus playsinline on any autoplay video. Those handful of fixes cover most of the differences.

Why is my Meta pixel showing fewer conversions than my actual sales?

Safari's Intelligent Tracking Prevention limits or blocks the cookies your pixel relies on, which means conversions from iPhone visitors are often under-reported. Setting up server-side tracking through Meta's Conversions API alongside the browser pixel gives you a far more accurate picture, particularly for any audience with a lot of iPhone users.

Does Chrome DevTools' mobile view count as testing on Safari?

No, and this trips up a lot of people. DevTools' device mode only resizes the Chromium browser window, it does not switch rendering engines, so none of Safari's actual bugs (viewport height, flexbox gap, autofill styling) will show up. The only reliable test is a real Safari browser, ideally on a real iPhone.

Prefer to hand this over? Start here: contribute a guest article on web design.