Chrome добавляет поддержку JPEG XL с версии 155: декодер на Rust

6 октября 2026 года в блоге Chrome для разработчиков команда браузера объявила: Chrome начинает поддерживать декодирование формата изображений JPEG XL (.jxl) начиная с версии Chrome 155. Авторы описывают JPEG XL как формат нового поколения для веб-разработчиков и фотографов и приписывают ему сжатие на 30-50% лучше, чем у JPEG (условия измерения в посте не приводятся), а также сжатие без потерь, встроенную поддержку HDR и перекодирование JPEG без потерь.

Главный технический акцент, безопасность. Декодеры изображений, пишут авторы, одна из самых атакуемых поверхностей браузера: они разбирают сложные недоверенные двоичные данные прямо из сети внутри процесса отрисовки, а декодеры на небезопасных с точки зрения памяти языках вроде C++ исторически подвержены выходам за границы буфера, переполнению кучи и use-after-free. Песочница и многоуровневая защита (с отсылкой к «правилу двух») названы вторичным слоем обороны, поэтому, чтобы устранить риски в корне, Chrome интегрировал jxl-rs, чистую реализацию декодера JPEG XL на Rust.

При этом команда стремилась к скорости: безопасный по памяти декодер, который примерно так же быстр, как лучшая небезопасная альтернатива, гораздо более очевидный выбор, чем вариант со значимой потерей производительности. Для безопасного использования SIMD-инструкций потребовалась стабилизация возможности Rust target_feature_11, позволяющей применять SIMD без unsafe-кода. Затем построили слой абстракции jxl_simd, вдохновлённый C++-библиотекой Highway (она изначально разработана для libjxl, эталонной реализации JPEG XL на C++). В итоге небезопасные операции ограничены небольшим числом тщательно проверенных мест. Оптимизации в jxl-rs опираются на те, что есть в libjxl, включая универсальный конвейер обработки шагов, пересекающих границы областей, с минимумом копирований данных. Производительность на разном железе отслеживается на отдельной панели jxl-rs performance dashboard.

Реализацию проверяли современными методами, включая фаззинг и ИИ-ревью кода, и, по утверждению авторов, не нашли ни одной ошибки безопасности памяти за всю историю разработки jxl-rs.

Решение о выпуске, по словам команды, опирается на последовательные отзывы и запросы веб-разработчиков, прежде всего в процессе Interop, где JPEG XL был популярным предложением в 2026 году и несколько лет до этого. Для совместимости между браузерами Chrome участвовал в Interop 2026 JPEG XL Investigation, чтобы тесты покрывали все возможности формата и проходили в Chrome.

Практическая рекомендация: пробовать и AVIF, и JPEG XL, чтобы получить лучший результат. Команда ожидает, что JPEG XL будет наиболее полезен для сжатия с высокой точностью или без потерь, особенно для фотографий, и там, где важна тонкая прогрессивная загрузка. Разработчиков призывают пробовать .jxl-изображения и анимации в своих конвейерах и сообщать об ошибках. В благодарностях выделены Helmut Januschka (вклад и в интеграцию в Chrome, и в jxl-rs) и Martin Bruse, Zoltan Szabadka, Sami Boukortt и Wonwoo Choi (вклад в сам jxl-rs).

Ключевые факты

Chrome начинает поддерживать декодирование JPEG XL (.jxl) с версии Chrome 155; в посте речь только о декодировании.
Используется jxl-rs, чистая реализация декодера на Rust, чтобы убрать риски безопасности памяти в одной из самых атакуемых частей браузера.
Авторы заявляют: фаззинг и ИИ-ревью кода не выявили ни одной ошибки безопасности памяти за всю историю jxl-rs.
Для скорости потребовалась стабилизация target_feature_11 в Rust и новый слой SIMD-абстракции jxl_simd, вдохновлённый библиотекой Highway.
Для JPEG XL заявлено сжатие на 30, 50% лучше JPEG; Chrome советует пробовать и AVIF, и JPEG XL.

Почему это важно

Chrome, один из главных браузеров, и поддержка формата в нём меняет практическую ситуацию для сайтов: JPEG XL становится форматом, который можно рассматривать для реального использования в вебе. Вторая линия сюжета, выбор Rust для декодера: команда прямо называет декодеры изображений критичной атакуемой поверхностью и утверждает, что реализация на Rust устраняет целый класс уязвимостей памяти при производительности, близкой к лучшим небезопасным аналогам (это цель проектирования, заявленная в посте).

Кому это важно

Веб-разработчикам и владельцам сайтов, которые оптимизируют изображения; фотографам и тем, кто публикует фото высокого качества или HDR; разработчикам браузеров и кодеков, которым интересен опыт внедрения декодера на Rust и SIMD без unsafe-кода.

Как это применить

Авторы рекомендуют пробовать и AVIF, и JPEG XL и сравнивать результат на своих изображениях. По их ожиданиям, JPEG XL наиболее полезен для сжатия с высокой точностью или без потерь, особенно для фотографий, и там, где нужна тонкая прогрессивная загрузка. Они призывают использовать .jxl-изображения и анимации в своих конвейерах и сообщать об ошибках. Дата выхода стабильной версии Chrome 155 в посте не указана.

Можно ли доверять

Источник, официальный блог Chrome для разработчиков, то есть первоисточник решения. Но это же самоописание команды: цифра «30-50% лучше JPEG» приведена без условий теста, набора изображений и метрики качества, а утверждение об отсутствии ошибок памяти в jxl-rs, слова авторов о собственных проверках. Конкретных замеров скорости декодера в тексте нет, есть лишь ссылка на панель производительности.

Риски и подводные камни

В посте не сказано, включена ли поддержка JPEG XL по умолчанию или за флагом, и не упомянуты другие браузеры, так что рассчитывать на поддержку у всех пользователей нельзя. Речь идёт только о декодировании; про кодирование в Chrome ничего не говорится. Заявленная скорость, цель проектирования, а не опубликованный результат тестов. Отсутствие найденных ошибок памяти не гарантирует отсутствия других классов ошибок.

«В целом мы рекомендуем попробовать и AVIF, и JPEG XL, чтобы получить лучшие результаты.»

— Команда Chrome, блог Chrome для разработчиков