# Real Safari vs WebKit: Which Tools Automate Real Safari? (2026)

Safari accounts for nearly one in five browser sessions. We compare five automation tools, explain why WebKit isn't the same as real Safari, and examine ten documented Safari compatibility issues across widely used web libraries.

Published October 27, 2026 by Liviu Lupei on the Endtest blog. Canonical URL: https://endtest.io/blog/real-safari-vs-webkit-automated-testing

---
*Five tools compared, ten documented Safari compatibility defects, and a practical way to automate Safari without maintaining your own Macs.*

**By Liviu Lupei, Solutions Architect at Endtest**  
**Published October 27, 2026 · Last updated October 27, 2026**

> ## Key takeaways
>
> - **Selenium (via SafariDriver), BrowserStack, and Endtest can automate real Safari on macOS.** Playwright and Cypress run WebKit, the engine inside Safari, which is closely related but not the same browser.
> - **Safari accounted for 18.27% of worldwide browser usage in September 2026,** according to Statcounter.
> - **WebKit and Safari have behaved differently in public bug reports.** Three recent Playwright issues and ten library defects are reviewed below, each linked to its original report.
> - **Run critical workflows in real Safari.** Checkout, login, file uploads, and rich-text editors are where browser differences cost the most.
> - **Disclosure:** Endtest, one of the five tools compared, publishes this article. The comparison is based on documented capabilities, not on a timed benchmark.

Safari accounted for **18.27% of worldwide browser usage in September 2026**, according to [Statcounter](https://gs.statcounter.com/browser-market-share/all-worldwide).

That's close to one in five browser sessions.

And yet, I still see teams treating Safari as the browser they'll check after everything else is done. Someone with a Mac opens the site, clicks around for ten minutes, and declares it compatible.

It's understandable. Developers tend to spend a lot of time in Chrome. Their debugging tools are familiar. Their automation suites run there. And when a feature works in Chrome, it's tempting to assume the job is finished.

Your customers don't share that assumption.

Some use Safari because they appreciate Apple's privacy and security approach. Others don't like Chrome. Plenty of Mac and iPhone owners simply use the browser that came with their device.

If your checkout breaks in Safari, they're unlikely to install Chrome to do you a favor.

They'll probably leave.

The good news is that Safari testing can be automated. The catch is that not every tool claiming Safari compatibility actually runs tests **in Safari**.

That distinction is worth understanding before choosing a testing framework.

## Why does Safari compatibility matter?

Accessibility has specific standards and practices: screen-reader support, keyboard navigation, appropriate contrast, semantic markup, and more. Cross-browser compatibility isn't a replacement for any of those.

But both disciplines are concerned with removing barriers.

If somebody can't complete a purchase because a button fails in their browser, the application isn't usable for that person. Telling them the same button works in Chrome doesn't help.

With Safari accounting for roughly 18% of worldwide browser usage, compatibility is not a corner case. And the most useful browser mix for *your* testing strategy should be informed by your own traffic, not just a worldwide average.

## Is manually checking Safari enough?

The simplest way to test Safari is to open Safari.

Maybe you own a Mac. Maybe a colleague has one. Maybe you're using a remote Mac through a testing service.

You load the homepage, click a few buttons, check whether the layout looks right, and move on.

You've learned that those particular interactions worked.

What about the rest?

Consider a typical online purchase. The customer selects a product variation, applies a discount, signs in, enters shipping information, completes a payment authentication challenge, and returns to the order confirmation page.

A failure could be hiding anywhere in that sequence.

The same goes for SaaS applications. Password resets, two-factor authentication, file uploads, rich-text editing, embedded dashboards, and account settings contain more browser-sensitive behavior than a homepage ever will.

Manual exploratory testing is still useful. But repeating every critical workflow in four browsers after every release is not a sustainable regression strategy.

The better approach is to **create automated tests for complete user journeys and execute them across the major browsers without rewriting the tests**.

There's one detail that teams sometimes miss.

## Is WebKit the same as Safari?

No. WebKit is the open-source engine inside Safari, but Safari is a complete browser built on top of it, with Apple's own security policies, media frameworks, and operating-system integrations.

Safari uses **WebKit**, an open-source browser engine.

But an engine isn't the same thing as a complete browser.

Think about a car engine. You can put the same engine in two different cars without making the cars identical. The transmission, electronics, suspension, and other systems still affect how they behave.

A browser is similar.

Safari combines WebKit with Apple's own browser functionality, security policies, media frameworks, networking behavior, and operating-system integrations. It also ships a specific WebKit revision as part of a particular Safari release.

A standalone WebKit build used by an automation framework may differ from that shipping version. And the operating system makes a difference too.

Running WebKit on Linux does not reproduce every detail of running Safari on macOS. Fonts, media codecs, native controls, permissions, graphics, and operating-system services can behave differently.

This isn't speculation. [Playwright's browser documentation](https://playwright.dev/docs/browsers) explains that it uses a patched WebKit build rather than branded Safari. It also recommends running WebKit on macOS, rather than Linux, for behavior closer to Safari in certain cases, including video playback.

That recommendation is useful. A WebKit build on macOS is often a closer approximation than one on Linux.

But an approximation is still not the application your users open.

If you need direct evidence that a workflow works in Safari, run it in **real Safari**.

## Which tools can automate real Safari?

For this comparison I looked at five familiar options: Endtest, Selenium, Playwright, Cypress, and BrowserStack.

The first question was simple: **can the documented workflow execute automated tests in Apple's actual Safari browser on macOS?**

| Tool | Actual Safari on macOS | Managed real-Safari infrastructure | Integrated AI testing capabilities |
| --- | --- | --- | --- |
| Endtest | Yes | Yes | Yes |
| Selenium | Yes, via SafariDriver | Not by itself | No native AI test-authoring workflow |
| Playwright | No; patched WebKit | Not for branded Safari | Yes; AI test agents |
| Cypress | No; experimental WebKit | Not for branded Safari | Yes; `cy.prompt()` |
| BrowserStack | Yes | Yes | Yes; varies by product and plan |

**Three of these five options can be used to automate actual Safari.** The others offer WebKit testing instead.

This is a comparison of **documented capabilities**, not a timed benchmark claiming that one tool executes faster than another. Capabilities were last checked against vendor documentation on October 23, 2026.

It's worth being precise about the categories. Selenium and Playwright are automation frameworks. BrowserStack is an infrastructure and testing platform. Endtest combines test creation, management, and execution. A company can use Selenium *with* BrowserStack rather than choosing one instead of the other.

Those distinctions matter when you calculate the real cost of operating a test suite. For a broader roundup beyond Safari, see our guide to the [best AI-powered test automation tools](https://endtest.io/blog/10-best-ai-powered-test-automation-tools).

Real Safari support is only one criterion. Here is how the tools differ on others:

| Tool | Cost model | How tests are authored | Where it stands out |
| --- | --- | --- | --- |
| Endtest | Commercial platform | Recorder and AI agents; editable steps | Managed real Safari with integrated AI test creation |
| Selenium | Open source | Code in several languages | Real Safari via SafariDriver, a large ecosystem, and full control |
| Playwright | Open source | Code (JavaScript/TypeScript, Python, Java, .NET) | Developer tooling and fast WebKit feedback |
| Cypress | Open-source test runner with commercial cloud services | Code (JavaScript/TypeScript) | Developer experience for front-end teams |
| BrowserStack | Commercial service | Runs your existing tests (such as Selenium); also offers low-code and AI products | Managed real browsers and devices at scale |

### Selenium: real Safari, but you manage the automation

Selenium can control actual Safari through [Apple's SafariDriver](https://www.selenium.dev/documentation/webdriver/browsers/safari/).

That's a major advantage for Safari compatibility testing.

The tradeoff is everything around it. You'll generally maintain the automation code, test dependencies, locators, CI configuration, and a suitable macOS execution environment, or pay for an external provider.

Selenium continues to be maintained and improved. What it doesn't provide is an integrated AI authoring and maintenance experience comparable to newer AI-first testing products.

Sure, Claude or Codex can generate Selenium scripts. But generated automation code is still code. Somebody needs to review it, understand it, debug failures, and keep it working as the application changes.

I don't think generating thousands of lines of scripts and repeatedly asking a coding agent to patch them is automatically a good maintenance strategy.

### Playwright: excellent WebKit coverage, not branded Safari

[Playwright](https://playwright.dev/docs/browsers) is a capable framework with excellent developer tooling. It can run the same test logic against Chromium, Firefox, and WebKit.

That's valuable for catching rendering and behavior differences early.

But Playwright explicitly states that it does **not** automate the branded Safari browser. It uses WebKit builds with patches, sometimes based on upstream changes that haven't yet appeared in shipping Safari.

That makes its results useful evidence about WebKit, not conclusive evidence about Safari.

### Cypress: the same underlying Safari distinction

[Cypress](https://docs.cypress.io/app/references/launching-browsers) supports experimental WebKit execution through the `playwright-webkit` package.

It's useful for teams that already like Cypress's workflow, but it doesn't turn those tests into real Safari sessions.

Cypress has also introduced AI assistance, including `cy.prompt()`. AI can make test authoring easier without changing which browser is actually being controlled.

### BrowserStack: real browsers with several ways to automate

[BrowserStack](https://www.browserstack.com/docs/automate/selenium/select-browsers-and-devices) provides cloud access to real Safari environments and can execute Selenium tests remotely. Its broader suite also includes low-code and AI-assisted testing products.

It's a serious option, especially if your team already owns a mature Selenium framework and wants managed browser infrastructure.

### Endtest: real Safari and integrated AI test creation

[Endtest](https://endtest.io/) takes a more integrated approach. You create and manage tests in the platform, then run them in actual browsers on real Windows and macOS machines.

When you select Safari, Endtest runs your web test in the real Safari application on macOS.

The same test steps can be executed in Chrome, Firefox, Edge, or Safari without manually rewriting the scenario for each browser.

And test creation doesn't have to start with automation code. The platform includes a recorder, an AI Test Creation Agent, Endtest Bot, AI Assertions, self-healing, and AI-assisted failure analysis.

For a team that wants **AI-powered test creation plus managed real Safari execution**, that's a particularly practical combination.

### Which tool should you choose?

- **Selenium on your own Macs:** you already have a Selenium framework and engineers to maintain it, and you want full control. You also take on the macOS infrastructure.
- **Selenium with BrowserStack:** you have an existing Selenium suite and want managed real Safari without owning Macs.
- **Playwright (WebKit):** you want fast developer feedback on WebKit and rendering behavior. Add real Safari validation for your critical workflows.
- **Cypress:** your team likes the Cypress workflow. Treat its experimental WebKit support as WebKit evidence, not Safari evidence.
- **Endtest:** you want tests created and maintained with AI, editable steps, and managed real Safari without maintaining automation code. The trade-off is that tests live in a commercial platform rather than in your own repository.

## What do real bug reports show about WebKit vs Safari?

The difference between Safari and WebKit isn't just a philosophical argument about browser architecture.

There are publicly documented cases where the environments behaved differently.

Here are three Playwright reports from September and October 2026 worth reading.

### 1. Mouse movement data differed between WebKit and Safari

In [Playwright issue #43417](https://github.com/microsoft/playwright/issues/43417), reported in October 2026, automated mouse movements in WebKit produced `movementX` and `movementY` values of zero.

The same sequence in Chromium and Firefox reported the expected coordinate changes. The issue reporter said real Safari also produced the expected deltas.

This matters for canvas editors, drawing interfaces, and controls that respond to the amount of mouse movement rather than just the final pointer position.

The Playwright team reproduced the issue and closed it after a fix.

### 2. Drag-and-drop returned a different effect

Another October 2026 report, [issue #43447](https://github.com/microsoft/playwright/issues/43447), described a difference in the `dropEffect` returned during drag-and-drop operations.

The reporter said Playwright WebKit returned `copy` when `move` was expected, while real Safari returned the expected value.

Applications with sortable lists, Kanban boards, draggable cards, or file managers could encounter problems if code depends on that behavior.

### 3. Some WebKit navigations stalled while Safari did not

A developer described an intermittent page-loading issue in [Playwright issue #42604](https://github.com/microsoft/playwright/issues/42604), filed in September 2026.

Under specific concurrent-navigation and streaming-response conditions, approximately 0.14–0.3% of navigations in their WebKit measurements failed to fire the page's `load` event. The report included runs of 16,800 navigations per test condition.

The reporter observed no corresponding stall in a smaller sample of real Safari navigations. Importantly, they also acknowledged that they couldn't produce a standalone reproduction of the complete issue.

That's useful evidence, but not proof that real Safari could never exhibit a related failure.

### These examples run in both directions

All three reports describe problems observed in Playwright WebKit that were **not** observed in real Safari by their reporters.

The reverse is also possible: something passes in a WebKit test but fails in the Safari release a customer is using.

That's the practical lesson. **A WebKit result should not automatically be treated as a real Safari result.**

## Which real Safari bugs have been reported in popular web libraries?

There is a much better way to understand Safari compatibility than imagining what *might* break: look at defects developers have actually documented.

I reviewed ten public bug reports involving Safari and widely used web components. Each includes an identifiable library, a concrete symptom, and a public issue thread. Some were filed in 2026 and others earlier; an old report doesn't mean the bug still exists in the current version. **These are third-party reports, not claims that Endtest discovered the incidents.**

| # | Component | Reported Safari behavior | Why a customer would care | Original report |
| --- | --- | --- | --- | --- |
| 1 | **Stripe.js / WooCommerce Payments** | `ApplePaySession` threw an `InvalidAccessError` inside a payment-enabled Stripe iframe on Safari, despite a secure HTTPS parent page. The reporter also described a related error during active Apple Pay checkout. | Apple Pay capability detection or an active Apple Pay transaction can fail. | [stripe-js #909, April 2026](https://github.com/stripe/stripe-js/issues/909) |
| 2 | **Radix UI Dialog** | With `modal={false}`, tabbing from a field into a custom control could move focus outside the dialog in Safari and cause the dialog to close. The reporter said it did not reproduce in Chrome or Firefox. | A customer filling out a multi-step form loses the active dialog before submission. | [radix-ui #3811, February 2026](https://github.com/radix-ui/primitives/issues/3811) |
| 3 | **Tiptap / ProseMirror** | Rapid text selection changes in an editor on iOS/iPadOS Safari reportedly stopped click handlers from firing elsewhere on the page. | Editing a document can leave Save, Publish, and navigation controls unresponsive until refresh. | [tiptap #7514, February 2026](https://github.com/ueberdosis/tiptap/issues/7514) |
| 4 | **hls.js** | A Safari live stream could encounter a decode error, after which recovery continued requesting older segments and ended with a black video element. The reporter said the implementation worked in Chrome and Edge. | Live video stops playing even though the page itself still loads. | [hls.js #7738, March 2026](https://github.com/video-dev/hls.js/issues/7738) |
| 5 | **TanStack Virtual** | Desktop Safari's elastic scroll bounce could discard a `scrollTop` adjustment when older messages were prepended to a chat-like list. The visible reading position jumped. | A user reading message history loses their place, with occasional blank rows during the transition. | [TanStack Virtual #1287, September 2026](https://github.com/TanStack/virtual/issues/1287) |
| 6 | **Material UI TextField** | An outlined field label rendered incorrectly in Safari when the field was placed inside a `Stack`. The reporter compared it directly with Chrome and Firefox. | Form labels look broken or become harder to read. | [MUI #46891, September 2025](https://github.com/mui/material-ui/issues/46891) |
| 7 | **Material UI search dialog / DocSearch** | On iPhone Safari, opening the search dialog after scrolling left the dialog positioned above the visible area rather than bringing it into view. | A customer taps Search and sees no usable search box. | [MUI #45407, February 2025](https://github.com/mui/material-ui/issues/45407) |
| 8 | **Tiptap editor** | Safari showed misplaced or invisible carets and inconsistent Backspace behavior around inline nodes marked `contenteditable=false`. | Editing structured text or inserting variables becomes unreliable. | [tiptap #7251, November 2025](https://github.com/ueberdosis/tiptap/issues/7251) |
| 9 | **PDF.js** | A Safari 16.6 report described a PDF viewer that displayed its toolbar but not the document after a PDF.js upgrade; the same build rendered in Chrome and Firefox. Maintainers pointed to the legacy build for that older Safari version. | A customer trying to review a contract or invoice sees a blank document. | [pdf.js #17992, April 2024](https://github.com/mozilla/pdf.js/issues/17992) |
| 10 | **Vaadin date-time picker** | Safari autofill could intercept the first click on a date-time field and prevent the calendar from opening until a second click. The issue was subsequently fixed. | A booking or appointment form appears unresponsive, especially to first-time users. | [Vaadin #6817, November 2023](https://github.com/vaadin/web-components/issues/6817) |

### Why do Safari checkout bugs matter most?

The Stripe report is particularly revealing. The parent page was served over HTTPS, the iframe carried a payment permission, and yet Safari's `ApplePaySession` call still threw a security-related exception. The reporter supplied browser breakdowns and error traces, not just a vague assertion that Safari was broken.

The report initially concerned capability detection during page loading; a later follow-up in the same issue described an error during an active Apple Pay shipping-selection step. Those are not identical failures, and the report does not establish that every Safari checkout failed. But it shows how a payment integration can run into browser-specific behavior at exactly the part of the journey where revenue is at stake.

### Why do Safari bugs slip past a quick visual check?

A focus trap that closes a dialog, an editor that stops responding, a scrolling list that loses its position, or a date picker that ignores the first click can all escape a quick visual inspection.

The value of automation isn't merely opening the page in Safari. It's reproducing the **full interaction**, then asserting something meaningful: the payment completes, the dialog remains open, the document saves, the selected date persists, or the chat stays at the expected message.

That's the kind of cross-browser coverage I would prioritize, and it's why execution in the actual Safari environment matters.

## How would you benchmark Safari automation tools?

Feature tables are a useful starting point, but the next question is how much work it takes to create and maintain the tests.

To compare tools fairly, I would use ten realistic workflows:

1. Account signup and login.
2. Password reset through email.
3. Two-factor authentication.
4. Shopping cart, coupon, checkout, and 3D Secure.
5. Account settings and persisted preferences.
6. Creating, editing, searching, and deleting records.
7. PDF uploads, downloads, and file validation.
8. Rich-text editing and saving content.
9. Navigation through iframes and multiple browser tabs.
10. Payment confirmation and receipt verification.

For each workflow, the most useful metrics are creation time, successful execution, execution duration, reliability across repeated runs, and repair time after a controlled interface change.

The evaluation needs to separate **browser support** from **authoring efficiency**. A Playwright WebKit run should not count as a completed test in real Safari. And if Selenium is running through BrowserStack, the benchmark should distinguish the Selenium framework from the cloud infrastructure provider.

We haven't published measured results yet, so this article makes no claims about which tool is faster, more reliable, or cheaper to maintain. What documentation does establish is which tools run actual Safari and which use WebKit. Comparing speed, reliability, and maintenance requires running these workflows under comparable conditions.

## How does Endtest run tests in real Safari?

We started building Endtest in 2015 and launched in 2016.

From early on, we made a deliberate choice about the infrastructure: automated browser tests should run in environments that closely resemble the ones used by actual customers.

For Endtest web tests, that means real browsers on real Windows and macOS machines, rather than relying exclusively on Linux-container browser engines.

We've kept that philosophy as the product has evolved.

When an Endtest test runs in Safari, it's running in Safari on macOS. Not merely in a WebKit build that happens to share much of the same rendering technology.

That distinction is important because the purpose of regression testing isn't to produce a green dashboard.

It's to find out whether important user journeys still work.

In practice, you choose the platform, operating system, and browser when you run a test or test suite. Select Mac and Safari, and the run executes in Safari on macOS.

![Endtest Run Test Suite dialog with Platform set to Mac, the Operating System field set to macOS Golden Gate, and the Browser dropdown open to show Google Chrome, Mozilla Firefox, Safari, and Edge](https://endtest.io/images/endtest-run-test-suite-safari-macos.png)
*Choosing the platform, operating system, and browser in Endtest's Run Test Suite dialog. Safari is one of four browser options on Mac.*

Each run records the environment it used. The results page shows the platform and browser, and offers Summary, Logs, Screenshots, and Video tabs, so a failure in Safari comes with evidence to inspect.

![Endtest test execution summary for a test named Online Store, showing Mac and Safari icons, status Finished, 19 steps, 1 passed assertion, 0 failed assertions, 0 errors, and a duration of 23 seconds](https://endtest.io/images/endtest-safari-test-execution-summary.png)
*An example Endtest execution summary for a 19-step test run in Safari on macOS. This is a single example run, not a benchmark.*

### One test can run across the major browsers

Suppose your application has a workflow that creates a new account, confirms the email address, logs in, uploads a document, and verifies the result in a dashboard.

In Endtest, you can create that test once and execute the same steps in Chrome, Firefox, Edge, or Safari.

You can also execute tests in parallel and connect them to CI/CD or a schedule.

You don't need a separate version of the workflow for each browser.

That's a small convenience when you have ten tests. It's a big difference when you have a few hundred.

## Can AI create and maintain Safari tests?

Real-browser infrastructure is only half the problem. Someone still has to build and maintain the tests.

This is where AI has been genuinely useful, provided it improves the testing workflow rather than simply generating more code for somebody to maintain.

### AI Test Creation Agent

With the [Endtest AI Test Creation Agent](https://endtest.io/docs/advanced/ai-test-creation-agent), you can describe a user journey in natural language.

For example:

> Open the application, create a user account, confirm the email, sign in, upload a PDF document, and verify that the document appears in the dashboard.

The agent can navigate the application and construct editable Endtest steps. That test can then be executed in real Safari, along with the other supported browsers.

### Endtest Bot

[Endtest Bot](https://endtest.io/product/create/endtest-bot) approaches the problem differently.

Instead of specifying one workflow at a time, you let the agent explore an application and generate tests for the scenarios it discovers.

The resulting tests are standard Endtest tests, which means they can be reviewed, edited, scheduled, and executed across browsers.

### Self-healing and AI failure analysis

Application interfaces change constantly. Attributes get renamed, buttons move, and entire components are replaced.

Endtest includes self-healing to help recover from certain locator changes, as well as AI Assertions, AI Variables, and AI-powered failure analysis.

The last one is useful when a test succeeds in Chrome and fails in Safari. Instead of beginning with a vague "Safari is broken" report, the team can inspect the actual execution evidence and investigate the failing step.

AI should reduce unnecessary maintenance work, not disguise real application failures. If you're thinking about autonomous test creation more broadly, see our article on [test automation in AI software factories](https://endtest.io/blog/test-automation-ai-software-factory).

## What should you test in Safari on every release?

You don't need to run every possible combination on every browser version after every commit.

Start with the workflows that matter most to your users and business:

- Account creation, login, password reset, and two-factor authentication.
- Checkout, payment authentication, discounts, and order confirmation.
- File uploads, downloads, previews, and PDF generation.
- Multi-tab navigation, popups, embedded frames, and third-party sign-in.
- Rich-text editors, date pickers, dashboards, and other complex UI components.

Run them in actual Safari alongside Chrome, Firefox, and Edge. Prioritize browser versions according to your visitor analytics, and add real iPhone testing when mobile Safari behavior is important.

And keep WebKit in the mix if it helps your team get quick feedback during development.

The point isn't that WebKit is useless. It's that **WebKit and Safari answer related but different testing questions**.

## What about Safari on iPhone, Windows, and headless mode?

- **iPhone:** desktop Safari on macOS doesn't reproduce every mobile Safari behavior, touch interaction, or iOS-specific integration, so important mobile traffic needs real iPhone testing.
- **Windows:** Apple no longer ships Safari for Windows, so real Safari automation needs macOS.
- **Headless:** SafariDriver controls a regular Safari window and has no headless mode, so plan for a macOS machine with a display session or a managed service.

New to test automation? Our guide to [the easiest way to automate tests](https://endtest.io/blog/what-is-the-easiest-way-to-automate-tests) is a good place to start.

## Frequently asked questions

### Which tools can automate real Safari?

Selenium (through SafariDriver on macOS), BrowserStack, and Endtest can run automated tests in Apple's actual Safari browser. Playwright and Cypress run WebKit instead, which is related to Safari but not the same browser.

### Can Playwright automate real Safari?

Not through its supported WebKit browser project. Playwright uses a patched WebKit build rather than Apple's branded Safari application. It's valuable for WebKit compatibility testing, but it shouldn't be treated as identical to Safari execution.

### Does Selenium support Safari?

Yes. Selenium automates Safari through SafariDriver on macOS. Teams can run it on their own Macs or use compatible remote infrastructure.

### Does Cypress run tests in Safari?

Cypress supports experimental WebKit testing through `playwright-webkit`. That is not the same thing as automating the actual Safari browser.

### Can I run Safari automation without owning a Mac?

Yes. Endtest and BrowserStack provide managed access to real Safari environments on macOS.

### Can AI create tests that run in Safari?

Yes. Endtest can create editable tests through AI-assisted workflows and execute them in real Safari. You can also use coding agents to generate Selenium tests that run through SafariDriver, although you'll still maintain the generated code and framework.

### Is testing WebKit enough to guarantee Safari compatibility?

No. WebKit and Safari share important underlying technology, but browser versions, patches, platform integrations, and operating-system behavior can lead to different outcomes. Critical workflows should be validated in the actual target browser.

### Should I also test Safari on a real iPhone?

Yes, if iPhone users are important to your application. Desktop Safari on macOS doesn't reproduce every mobile Safari behavior, touch interaction, or iOS-specific integration.

### Can I run real Safari tests on Windows?

No. Apple no longer ships Safari for Windows, so real Safari automation needs macOS. Managed services such as Endtest and BrowserStack provide macOS machines remotely.

### Does Safari have a headless mode?

SafariDriver controls a regular Safari window and doesn't offer a headless mode. If you need headless runs for speed in CI, WebKit through Playwright is a common choice, with real Safari reserved for critical workflows.

## The bottom line

I don't think teams should have to choose between meaningful browser coverage and manageable test maintenance.

We have the tools to automate complex user journeys, run them across browsers, and use AI to reduce the work involved in creating and updating tests.

The crucial detail is knowing what environment you're validating.

WebKit tests give you evidence about WebKit. They don't automatically prove that the same workflow works in the Safari release your customer is using.

If Safari compatibility matters, run tests in real Safari.

That's the approach we've followed at Endtest for years, and it's still the one I recommend.

Because your customers aren't using an automation framework.

They're using a browser.

And that's the environment your tests should ultimately verify.

---

### About the author

**Liviu Lupei** is a Solutions Architect at [Endtest](https://endtest.io/), a test automation platform started in 2015 and launched in 2016, with 15 years of experience in Quality Assurance. His work involves building automation infrastructure and working with QA and engineering teams across a range of industries, including retail, payments, healthcare, and travel.

### Sources and further reading

- [Statcounter — Worldwide browser market share, September 2026](https://gs.statcounter.com/browser-market-share/all-worldwide)
- [Playwright — Browsers and WebKit differences](https://playwright.dev/docs/browsers)
- [Cypress — Launching browsers and experimental WebKit support](https://docs.cypress.io/app/references/launching-browsers)
- [Selenium — SafariDriver](https://www.selenium.dev/documentation/webdriver/browsers/safari/)
- [BrowserStack — Selecting browsers and devices for Selenium automation](https://www.browserstack.com/docs/automate/selenium/select-browsers-and-devices)
- [Playwright issue #43417 — Mouse movement deltas in WebKit](https://github.com/microsoft/playwright/issues/43417)
- [Playwright issue #43447 — Drag-and-drop difference](https://github.com/microsoft/playwright/issues/43447)
- [Playwright issue #42604 — Intermittent WebKit load-event stalls](https://github.com/microsoft/playwright/issues/42604)
- [Endtest — Documentation and cross-browser capabilities](https://endtest.io/docs)