Something strange started happening one day. Website owners using Poptin noticed their lead capture forms stopped working. But only for Safari users!

TLDR: Safari users couldn’t submit Poptin forms because of a browser update tied to CORS rules. This caused tons of lost leads and headaches. The fix? A clever workaround using fetch with a new fallback mechanism. Now conversions are flowing again—and Safari is still invited to the party.

Broken Forms? Not on Chrome…

Poptin is a popular tool for collecting leads through popups and forms. Everything worked like a charm—on Chrome, Edge, Firefox. But on Safari? Crickets. People would fill out the form, click submit, and… nothing. The form didn’t go through.

It wasn’t just one or two reports. The issue grew fast. Entire campaigns saw sudden drops in leads. Especially from iPhone and Mac users. And since Safari is the default on Apple devices, that’s a big slice of traffic.

The forms weren’t truly broken. They just couldn’t complete the submission because of how Safari was handling network requests.

Meet CORS – The Gatekeeper

To understand what caused the chaos, let’s talk about CORS.

CORS stands for Cross-Origin Resource Sharing. It’s a security rule built into browsers. It decides which websites can talk to each other. For example, if your form submits data to another domain (say, api.poptin.io), CORS decides if that’s allowed.

It’s like a bouncer at a club. If the script doesn’t have the right invites, it’s not getting in. For years, this wasn’t a big problem. Until Safari got strict.

Safari Tightens the CORS Rules

In a recent update, Safari decided to enforce even tighter CORS checks by default. Legitimate calls that worked fine before were now being blocked unless every header and behavior was perfectly aligned with Apple’s new standards.

Even though Poptin was using a script to send the form data using XMLHttpRequest, Safari flagged those requests as unsafe. The result? Submissions failed silently. No error for the user. No lead for the site owner.

Ouch. What Did This Break?

The main issue was the form submissions didn’t complete. That meant:

• No emails collected
• No CRM integrations triggered
• No analytics tracking
• No thank-you messages

And worst of all, no way to know something was wrong. If you didn’t manually test your site on Safari, you’d have no idea leads were being lost.

Time to Investigate

The Poptin team jumped into action. First, they tested the same popup across browsers. Sure enough:

• Chrome: ✅
• Firefox: ✅
• Edge: ✅
• Safari: ❌

Next, they dug into the dev tools. That’s when it became clear. Safari was canceling the request due to forbidden CORS behavior. The requests didn’t have the right headers. Or, more precisely, Safari didn’t like the way the form script sent the data.

Enter the Fetch API

Solution time. Instead of using XMLHttpRequest—an older way to send HTTP requests—they decided to rewrite the form submission logic using the newer fetch API.

Fetch is more modern and flexible, especially for handling CORS. With fetch, you can:

• Customize headers
• Control credentials and mode
• Use async/await for smoother error handling

Poptin switched to fetch with CORS mode explicitly set, like this:

fetch('https://api.poptin.io/form/submit', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json'
  },
  mode: 'cors',
  body: JSON.stringify(data)
}).then(...);

This helped—but only partly.

Still Some Fails on Safari

Some Safari users still weren’t getting through. It turned out other permissions, around cookies and headers, were still sketchy. Poptin needed a backup plan—so they built one.

Plan B: The Fallback Mechanism

If Safari didn’t like the direct request, then maybe another method would work. The team implemented a fallback layer, right inside the script.

Here’s how it worked:

1. Try fetch with CORS
2. If that fails or times out, create a hidden iframe
3. Post the data to the iframe’s URL instead
4. Server receives the iframe post and processes it
5. Response is handled silently with JavaScript

This worked like a charm because it avoided CORS entirely in the fallback. The user never knew the switch happened. But the form submitted, the lead was saved, and everyone smiled again.

What Changed After the Fix?

Once the new fetch + iframe fallback was released, the difference was immediate.

Conversion rates from Safari jumped back up. Form completion time went down. Support tickets from confused marketers? Stopped coming in.

Here’s what improved:

• 99.8% success rate across all browsers
• Faster response handling with modern fetch APIs
• Graceful degradation for older or stricter environments

It also gave Poptin the chance to modernize some of its code and make things faster for everyone—not just Safari users.

What You Can Learn From This

If you’re a web developer or marketer relying on lead forms, here’s what you should take away from this curly Safari situation:

• Always test your forms on all major browsers. Don’t assume they all behave the same way.
• Monitor conversion rates by browser. A sudden drop might mean more than bad traffic.
• Use fetch for modern forms, but also be ready to handle requests in other ways.
• Handle failures gracefully. Fallbacks might seem old-school, but they can save the day.

The Safari Problem Wasn’t the End

Browser behaviors continue to change. What works one day may break the next. Especially with privacy-focused companies like Apple pushing strict policies.

But clever developers will always find a way. Whether it’s via fetch, fallback iframes, or magic—well, mostly code—it’s all about making sure users have a smooth experience.

Wrapping Up

One sneaky browser update led to a major lead-capturing headache. But it also led to a better solution. Thanks to fetch and fallback mechanisms, Poptin forms are now stronger than before. Cheers to smart debugging, modern APIs, and a little old-school creativity.

Safari, we forgive you… this time.