Microsoft Edge 155 Adds JPEG XL Decoding Support
Microsoft has released Edge 155 for Windows, macOS and Linux. The browser now supports JPEG XL decoding, and unload handlers no longer run by default.
On October 8, 2026, Microsoft released the stable version of Edge 155 for Windows 10/11, macOS and Linux. According to Habr, the update includes bug and security fixes, new policies and JPEG XL decoding support. For teams maintaining websites, the changes to image handling and the unload event are especially important.
JPEG XL and what happens when users leave a page
Edge 155 can now decode JPEG XL images. This matters for websites that already use the format or are considering it for their content. But Edge support alone does not establish image compatibility for a site’s entire audience: the report does not describe how other browsers handle the format. For more context, see the news about JPEG XL support in Chrome 155.
The second change concerns the unload event. Edge has been gradually disabling its handlers by default while allowing sites to explicitly enable them through Permissions Policy. In versions 152 and 153, the new behavior applied to 60% of page loads; in version 154, it applied to 80%. In Edge 155, that figure has reached 100%. This does not mean it is now impossible to enable the handler, but sites can no longer count on it running without explicit permission.
For developers, this is a reason to review actions tied to a user leaving a page. If an important part of the logic relies specifically on unload, its previous behavior in Edge can no longer be taken for granted. The report advises developers to use appropriate lifecycle events and APIs. The change goes beyond a single browser release: in the longer term, the web platform is moving toward dropping unload entirely.
Security, tabs and plans for upcoming versions
Edge 155 includes security fixes from the Chromium project, along with patches for vulnerabilities specific to Edge. The report does not list individual vulnerabilities, so it cannot be used to assess how a particular fix affects a website or device. Beyond security, the update includes bug fixes and new policies.
Microsoft is developing tools for organizing tabs and workspaces. Available options include grouping, names, visual styling and labels. Users can manage these features through the “Allow Microsoft Edge to help organize your tabs” setting at edge://settings/privacy/services. Administrators can use the TabServicesEnabled policy for this.
Some changes concern future releases. The move from legacy direct sign-in through Windows Web Account Manager to OneAuth is expected to be completed in Edge 157. WAM will remain part of the system; some users may need to sign in to the browser again. This is a change to sign-in, not the end of WAM support.
Real-time video translation is no longer supported, and the LiveVideoTranslationEnabled policy will be removed in a future update. The removal date for the LocalNetworkAccessRestrictionsTemporaryOptOut policy, by contrast, has been pushed back: it is now planned for after Edge 163, rather than after version 156 as previously indicated.
Since late August 2026, Edge has been released every two weeks instead of on the previously planned four-week cycle. With that schedule, it helps to distinguish between behavior already in effect in version 155 and changes that, for now, have only future timelines.
What website teams should check
If a website uses JPEG XL or the team is only planning to adopt it, it is worth checking the relevant pages and images in Edge 155. Decoding support confirms that the browser can handle the format, but it does not replace testing the scenarios and browsers that matter for a particular site. If the project does not use JPEG XL and there are no plans to introduce it, this release does not call for a separate format check.
The other check concerns pages whose code depends on unload. Teams need to find out whether those scenarios exist and what happens when a user leaves the page in the updated Edge. Without explicit permission from the site, the handler now does not run by default for 100% of page loads. If a necessary action depends on this event, developers will need to reconsider its implementation using lifecycle events and suitable APIs.
Website owners and marketers do not need to dig into Permissions Policy or browser settings themselves. It is enough to ask the team whether the site uses JPEG XL or unload, then arrange to test the pages affected. This conversation helps keep image compatibility separate from changes to page behavior: the two issues have different conditions and require different checks.
My take
I would start with one important user journey: when the team looks at a specific live page together, it is easier to agree on what actually needs fixing and what remains an assumption. That conversation connects the design, interface behavior and implementation options without requiring an immediate review of the entire site.
Sources
Where the news comes from. The text is a retelling in the author’s own words; the facts come from the source, the opinion is the author’s.
- Релиз Microsoft Edge 155 habr.com
Digital product art director
I design interfaces and help teams agree on a visual system. If there are doubts, we can start with one screen and test it with real people.
All posts by the authorRelated articles
Chrome to Add JPEG XL Support Starting with Version 155
Starting with Chrome 155, the browser will be able to open JPEG XL images. Site owners should compare the format with AVIF and check browser support before changing file formats.
Google Images and Discover Don’t Yet Support JPEG XL for Previews
Google Images and Discover don’t yet use JPEG XL for images or previews, despite support in Chrome and Firefox. For search, it’s worth keeping a fallback file in a supported format.
Next.js Releases Security Updates for Versions 15.5 and 16.3
Next.js has released versions 16.3.8 and 15.5.27 to fix vulnerabilities involving caching, information disclosure, and image optimization. Teams are advised to update their apps and check which features they use.
Discussion 4
Tетяна Зубко
On a content-heavy redesign, we checked new image formats in the actual upload and preview flow, not just on a standalone test page—CMS previews and older assets can behave differently. For JPEG XL, I’d include transparent images and responsive variants in that check so the visual result stays consistent across the site.
Nicolae Nistor
@tania_zab, checking the real CMS path is the part that tends to catch problems a standalone decode test misses—especially if previews generate their own responsive variants. I’d also verify what happens when a JPEG XL upload falls back to an older format, rather than assuming Edge 155 support means the same asset works across the audience. Do you have a clear success criterion for the preview and published page, such as matching transparency and crop across formats?
Vasilis Iacovou
@nikita.nistor I’d make the fallback check part of the acceptance test too: compare the JPEG XL and fallback at the same responsive breakpoints, since a CMS can regenerate dimensions or crops along the way. That gives you a practical pass/fail beyond whether both previews merely load.
Tетяна Зубко
In projects I’ve worked on, leaving-page handlers often ended up carrying important tasks like saving a draft, so we treated them as a safety net rather than the only save path. With Edge changing the default, I’d test that workflow in a real browser and make saving explicit before users navigate away.