Safari 27's Biggest Feature Is 844 Bug Fixes

The WebKit team published its release notes for Safari 27.0 on 17 September. It ships with macOS 27, iOS 27, iPadOS 27 and visionOS 27, and is available separately for macOS 26 Tahoe and macOS 15 Sequoia. The feature count grew from 58 at the first beta in June to 83 at release. But the number the WebKit team chose to lead with is fixes: 525 were announced at WWDC, and the final release contains 844.

For web developers, that emphasis is the right one. Safari has spent years as the browser you test last and patch around. A release that deliberately prioritises the correctness of existing features is worth more to most teams than another round of new CSS.

Top-level await, finally fixed properly

The most important change for anyone shipping JavaScript modules is a complete rewrite of Safari's ES module loader. According to WebKit, the old loader was based on a WHATWG Loader proposal from 2016 that was later abandoned and that predated top-level await. The new loader is written in native C++ and follows the ECMAScript specification's module algorithms directly.

The practical effect is the end of a class of ordering bugs where a module could see another module's exports before they had finished evaluating. That was a real source of cross-browser problems in apps that use top-level await for configuration or lazy initialisation, and teams worked around it by restructuring code. Those workarounds can now be retired once Safari 26 drops out of your support matrix.

The rest of the fix list rewards scrolling. There are 66 SVG fixes alone, including a review of the SMIL animation engine, plus rebuilt CSS zoom and subpixel inline layout. One example captures the theme: combining -webkit-line-clamp with text-wrap: balance on the same element previously meant the balancing never happened. That is now fixed.

The new features worth testing

• Customisable select. Setting appearance: base-select turns a real <select> into a fully styleable control, with new pseudo-elements such as ::picker-icon and ::checkmark, HTML inside options, and a <selectedcontent> element. Because it is still a native form control, keyboard handling, screen readers and form submission come for free. Apple changed its default styles after the June beta and has taken them to the CSS Working Group; until other engines align, expect the unstyled look to differ between browsers.
• Scroll anchoring. Safari now keeps the user's place when content is inserted above the viewport, controlled by overflow-anchor, which defaults to auto. This is on for every site automatically. If your app manages scroll position itself, as chat interfaces and infinite feeds often do, test it, and use overflow-anchor: none where your own logic should win.
• The stretch sizing keyword for width, height and flex-basis, which is a cleaner way to fill available space than the usual percentage and box-sizing tricks.
• WebAssembly JSPI, which lets synchronous-style Wasm code suspend while waiting on JavaScript promises. That makes porting C, C++ and Rust code with blocking I/O far easier.
• Service Worker static routing, so a service worker can declare requests that skip it entirely. For PWAs where the worker sits in front of every fetch, that is a direct latency saving.

An MCP server in the browser

The feature Apple put first is a Safari MCP server, which lets coding agents inspect the DOM, network requests, console output and screenshots in a real Safari window. WebKit says it runs entirely locally, makes no network calls of its own, and has no access to personal browsing data. It is off by default and has to be enabled in Safari's Developer settings.

The interesting part is not the agent angle but the testing one. Getting automated, scriptable access to Safari's rendering has historically been more awkward than for Chromium. If this becomes a convenient way to check layouts in WebKit during development, it could shrink the gap between "works in Chrome" and "works everywhere". I would still treat anything that hands a browser to an agent with care, and keep it switched off on profiles you use for anything personal.

The short version: update your Safari test devices, re-test anything involving module loading order and scroll restoration, and start planning which custom select components can be replaced with the native one.

---

Sources

• WebKit Features for Safari 27.0 (WebKit blog)