A release built for the code you already have
Apple shipped Safari 27 on September 14, 2026, alongside its fall operating system updates, and the WebKit team was unusually blunt about what kind of release it is. By their own count, it carries 58 new features, 525 bug fixes and 4 deprecations, and the WebKit blog frames the emphasis squarely on the fixes: existing features behaving more correctly, handling more edge cases, and interoperating with other browsers the way developers already expect them to. That framing matters more than it sounds. A browser release stuffed with new APIs is exciting to read about; one stuffed with fixes is the one that stops your site breaking in ways you never filed a bug for.
Still, three changes in Safari 27 are worth a developer's attention on their own merits.
Native dropdowns you can finally restyle
For as long as the web has had a <select> element, styling it has meant one of two bad options: leave it looking like an unstyled system control, or throw it away and rebuild the whole dropdown in JavaScript, at which point you also inherit the job of re-implementing keyboard navigation and screen-reader support that the native element gave you for free.
Safari 27 adds appearance: base-select, which lets a <select> be restyled to match a site's design while keeping its native keyboard and accessibility behavior intact underneath. It's a small property with an outsized practical effect: it removes one of the more common reasons teams reach for a JavaScript dropdown library in the first place.
WebAssembly gets a way to wait on a Promise
WebAssembly JavaScript Promise Integration (JSPI) is the more technical addition, and it solves a specific porting headache. Code compiled to WebAssembly from languages like C, C++ or Rust is frequently written in a synchronous, blocking style, call a function, get a result back immediately. JavaScript's async APIs, like fetch, don't work that way; they hand back a Promise that resolves later. Previously, bridging the two meant rewriting the WebAssembly side around callbacks. JSPI lets synchronous WebAssembly code suspend itself and wait on a JavaScript Promise directly, which means existing C, C++ and Rust codebases can be compiled to run in the browser without being restructured first.
Smaller but real: scroll anchoring and layout fixes
Safari 27 also turns on scroll anchoring by default, via overflow-anchor: auto. When content finishes loading above whatever you're currently looking at, an image, an ad, a comment thread, the browser now holds your scroll position on what you were reading rather than letting the page jump. It can be switched off per-element with overflow-anchor: none for the rare case where you want the old jumpy behavior back.
CSS anchor positioning, used for things like tooltips and popovers pinned to a trigger element, now correctly tracks an anchor that has a CSS transform applied to it, closing a gap that previously made transformed anchors behave unpredictably. A handful of smaller CSS additions round out the release: a :heading pseudo-class that matches any of <h1> through <h6> in one selector, a revert-rule keyword that rolls a property back to its value before the current rule applied, and a stretch sizing keyword that fills available space while correctly accounting for margins. Apple also extended the <model> element, previously aimed mostly at visionOS, to iOS, iPadOS and macOS, alongside new spatial and panorama controls on <img>.
What it means in practice
None of this requires an immediate rewrite. The dropdown styling and scroll anchoring changes are opt-in improvements you can adopt incrementally, restyle a form here, stop fighting a scroll jump there, without touching the rest of a site. JSPI matters mainly if you're maintaining or considering a WebAssembly build of an existing native codebase; for most web developers it's a capability other tools will quietly start relying on rather than something to reach for directly. The more durable value of this release is the 525 fixes nobody will individually notice: if a layout quirk or Safari-specific inconsistency has been on your team's backlog for a while, it's worth checking whether Safari 27 already made it someone else's problem to have fixed. Commentator John Gruber described this release as WebKit's own "Snow Leopard year," a nod to the 2009 Mac OS X release that shipped almost no new features and instead spent its entire cycle on stability and speed, and the comparison holds: the win here is fewer surprises, not more surface area to learn.
