Chrome начинает поставлять поддержку декодирования изображений в формате JPEG XL (.jxl) начиная с версии Chrome 155. Анонс опубликован 6 октября 2026 года. Речь идёт именно о декодировании: браузер распознаёт и отображает .jxl штатно, без отдельного флага. Поддержки кодирования в анонсе нет.
Что именно изменилось
Chrome поставляет поддержку декодирования JPEG XL начиная с версии 155. Это значит, что .jxl-изображения и анимации можно использовать в пайплайнах напрямую. Разработчикам, создателям контента и владельцам платформ предлагается начать применять .jxl в своих пайплайнах.
Для декодирования в Chrome интегрирована jxl-rs — чистая реализация декодера JPEG XL на Rust.
Почему декодер переписали на Rust
декодер изображенийкомпонент браузера, который разбирает бинарные данные изображения и превращает их в пиксели — одна из самых критичных и атакуемых поверхностей в браузере: он обрабатывает сложные недоверенные бинарные структуры прямо из сети и работает внутри процесса рендерерапроцесс браузера, в котором выполняется код страницы и который изолирован от остальной системы. Исторически декодеры на небезопасных для памяти языках, таких как C++, были подвержены уязвимостям вроде чтения за границами, переполнения кучи и использования после освобождения.
Модель безопасности Chrome опирается на песочницуизоляцию процесса, ограничивающую доступ к системе на случай компрометации и глубокую защиту по правилу двухпринципу, по которому код не должен одновременно обрабатывать недоверенные данные, работать на небезопасном для памяти языке и не иметь изоляции — иначе одного барьера для защиты недостаточно, но песочница — лишь вторичный слой защиты. Чтобы устранить риски у источника, и был интегрирован jxl-rs.
Скорость при этом оставалась требованием. Чтобы безопасно задействовать SIMDнабор инструкций процессора для параллельной обработки нескольких значений одной командой, потребовалось стабилизировать функцию Rust target_feature_11, которая позволяет включать такие инструкции для отдельной функции, не помечая её как небезопасную. Затем был создан слой абстракции SIMDпрослойка, скрывающая различия между наборами SIMD-инструкций разных процессоров за единым интерфейсом jxl_simd по образцу библиотеки C++ Highway. В итоге небезопасные операции ограничили небольшим числом тщательно проверенных мест, а проверка методами фаззинга и ИИ-ревью кода не выявила ошибок безопасности памяти за всю историю реализации.
Предыстория
Решение о поставке JPEG XL в Chrome основано на постоянных отзывах и запросах веб-разработчиков. Google и Mozilla откладывали поддержку до появления жизнеспособной альтернативы на Rust: «I think this validates Google's and Mozilla's decision to hold off until there's a viable Rust alternative». Это относится к задержке, а не к удалению.
Как на это повлиял Interop
Наиболее заметно запросы разработчиков проявились в Interop Processпроцесс, в котором браузеры договариваются о единой поддержке веб-технологий, чтобы один и тот же код работал одинаково во всех браузерах: формат был популярным предложением в 2026 году и за несколько лет до этого. Чтобы обеспечить совместимость между браузерами, команда Chrome участвовала в Interop 2026 JPEG XL Investigation — добиваясь тестового покрытия всех возможностей JPEG XL в браузерах и прохождения этих тестов в Chrome. Помимо этого команда учитывает отзывы из багов, опросов и Developer Signals Projectканал, через который разработчики сообщают браузерным командам о своих потребностях.
Что это меняет на практике
В Chrome 155 изображения .jxl можно использовать напрямую. Но поддержка в других браузерах различается:
- Chromium — за флагом с версии 91 по 109;
- Firefox — за флагом с версии 90;
- Edge — за флагом с версии 91;
- Opera — за флагом с версии 77;
- Safari — с версии 17;
- Waterfox — включён по умолчанию.
Поэтому <img src="*.jxl"> без полифилов и фолбэков работает не везде — только там, где браузер декодирует .jxl штатно. В целом рекомендуется пробовать и AVIF, и JPEG XL, чтобы получить лучший результат.
Инструменты кодирования
Для кодирования исходного изображения в JPEG XL с настройками по умолчанию используется cjxl, для декодирования — djxl. Настройки кодирования выбираются параметрами. --distance задаёт желаемую визуальную точность в единицах just-noticeable differencesпорог различимости: значение, ниже которого разница для глаза незаметна, где 0 — lossless, а наиболее полезный lossy-диапазон — 0.5 .. 3.0. --quality задаёт шкалу от 0 до 100, примерно соответствующую libjpeg. --effort выбирает усилие кодирования. Дополнительные настройки доступны через cjxl --help или полный список через cjxl -v -v --help.
Цифры
Типичный коэффициент сжатия JPEG XL — 20:1 — 50:1.
Ограничения и открытые вопросы
Авторы признают ряд незавершённых частей реализации. LF-кадрыкадры пониженного разрешения, которые кодируются отдельно и служат основой для прогрессивного декодирования для дополнительных каналов ещё не реализованы: при наличии alpha уровень 1первый уровень прогрессивного декодирования, на котором изображение отображается в пониженном разрешении не рендерится, а уровень 2следующий уровень прогрессивного декодирования с более высоким разрешением портит изображение, поэтому при дополнительных каналах прогрессивный DCпоэтапное декодирование, при котором сначала восстанавливается изображение в низком разрешении, а затем уточняются детали принудительно отключается.
Быстрый lossless-режим не применяется в ряде случаев: при анимации, кропе, если выбрана не самая быстрая ступень усилия кодирования, при кастомной битовой глубине, отличной от битовой глубины метаданных, при непустом имени кадра, при битовой глубине больше 16, а также при дополнительных каналах, кроме ровно одного alpha.
Для photon noiseсинтеза шума, имитирующего зернистость плёнки нет настройки 8 значений параметров синтеза на кадр — это ограничивает тонкий контроль. В размытии невидимых пикселей текущая реализация даёт размытие вниз и лишь дублирование края вверх на 1 пиксель; по замечанию авторов, лучше было бы размывать во всех направлениях, но это требует alpha-взвешенной свёртки с достаточно большим ядром.
