Safari 26.4 is here!
https://webkit.org/blog/17862/webkit-features-for-safari-26-4/
Grid Lanes. WebTransport. Keyboard Lock API. And _tons_ of fixes & improvements. Please read the introduction to our article to learn what we’ve been up to…

WebKit Features for Safari 26.4
March has a way of bringing a lot of new things to WebKit — and this year is no exception.
WebKitThe heart of this release is focused on what web developers ask for most. We hear you loud and clear. Results from 2025 developer surveys made it clear you want time to catch up with new features, not be swamped with more. You want existing features to work consistently across every browser. You asked for browser engineers working on WebKit to help you by squashing bugs and closing gaps in spec coverage. That’s what this release aims to do.
Most features listed in Safari 26.4 release notes are not new. Many update features where the behavior didn’t match the latest web standard. Others make combinations of existing features work better together… we shipped support for the CSS `min()` and `max()` functions in 2018, almost two years before any other browser… and the HTML `sizes` attribute for responsive images back in 2014. But you couldn’t use `min()`, `max()`, or `clamp()` inside of the `sizes` attribute in WebKit. Now you can.
And then there are the bug fixes — hundreds of them across the platform. WebKit engineers went deep to improve specific areas like SVG, Tables, MathML, and CSS Zoom. And we’re continuing our multi-year rewrite of the layout engine. Blocks-in-inline layout is complete in Safari 26.4, work on Flexbox continues, and we’ve now begun rewriting CSS Grid.
As we continue this work, we greatly value your input. If something has been bothering you, it’s worth testing in Safari 26.4 to see if it’s been fixed. If the bug is still there, please file it at bugs.webkit.org. Or if it’s already filed, add additional comments to the existing issue describing your experience and why fixing it matters for you.
When multiple websites signal that something needs fixing, that helps. The more concrete you can be — a brief story about why this hurts your users, a link to a real website affected, a snippet of code or reduced test case — the better equipped we are to prioritize and fix what matters most. We are paying attention, even if our response shows up as a shipped fix rather than a reply in the issue.
We care deeply about the experience people have when using Safari. And we care about the experience people have when using any of the millions of iOS, iPadOS, macOS, visionOS, and watchOS apps that are built using WebKit and JavaScriptCore.
When our customers open a news app, a shopping app, a travel app, a banking app — there’s a good chance the interface they’re interacting with is powered by the same HTML, CSS, and JavaScript you write every day when making web apps and websites that live at a URL. Every rendering fix, every improved feature, every performance gain we ship benefits everything touched by the web platform.