Возьмите одну фотографию на 12 МП (4000 × 3000 пикселей) и экспортируйте её шестью способами. PNG: 24 МБ. JPEG с качеством 90: 3,4 МБ. WebP с сопоставимым визуальным качеством: около 2,4 МБ. AVIF с сопоставимым визуальным качеством: около 1,7 МБ. GIF, ужатый дизерингом до своего потолка в 256 цветов: 6 МБ, с заметным бандингом повсюду. SVG в этот список не попадает: он описывает рисунки, а фотография не рисунок.
На экране одна и та же картинка, на диске разница в 14 раз. Этот разрыв инженерный, а не вопрос вкуса. Каждый формат это набор решений, принятых под ограничения конкретного года, и эти решения до сих пор видны в весе ваших страниц.
Это практическая версия того эксперимента: что каждый формат на самом деле делает с вашими пикселями, какие браузеры его декодируют в середине 2026 года, что веб реально отдаёт, и таблица в конце, которую можно вставить в командную вики.
Претенденты, по одному за раз
JPEG (1992). Механизм: изображение разбивается на блоки 8 × 8, каждый блок преобразуется в частоты дискретным косинусным преобразованием, затем мелкие детали квантуются к нулю по модели человеческого зрения. Сильные стороны: декодируется на любом устройстве, выпущенном с середины 90-х, кодируется быстро и отлично справляется с непрерывно-тоновыми фотографиями. Слабые стороны: нет прозрачности, нет анимации, заметный звон вокруг резких краёв и текста, а качество накапливает потери с каждым пересохранением. Подходит для фотографий и всего, что обязано открыться абсолютно везде.
PNG (1996). Механизм: полностью без потерь. Каждая строка пикселей фильтруется предиктором, затем упаковывается алгоритмом DEFLATE, той же связкой LZ77 плюс код Хаффмана, что и внутри gzip. Сильные стороны: попиксельно точный результат, полноценный альфа-канал, универсальная поддержка. Слабость это фотографии: шум матрицы обманывает предиктор, поэтому снимок на 12 МП сжимается разве что в 1,5:1 относительно исходных пикселей. Подходит для скриншотов, снимков интерфейсов, диаграмм и всего с текстом или ровным цветом.
GIF (1987). Механизм: сжатие LZW поверх палитры максимум из 256 цветов, с несколькими кадрами, упакованными в один файл. Единственная оставшаяся сильная сторона это анимация, которая проигрывается буквально везде, включая почтовые клиенты без поддержки современных форматов. Слабые стороны это всё остальное: 256 цветов, однобитная прозрачность и файлы, во много раз превосходящие эквивалентное видео. Подходит для мемов и небольших зацикленных анимаций в интерфейсе.
SVG (2001). Механизм: никакого, в растровом смысле. SVG это XML, описывающий фигуры, контуры и градиенты, а рендерер рисует пиксели в том разрешении, которое нужно экрану. Сильные стороны: независимость от разрешения, ничтожный размер для геометрической графики, стилизация через CSS. Слабые стороны: работает только с по-настоящему векторным содержимым, а патологические файлы с тысячами узлов и тяжёлыми фильтрами могут обойтись дороже битмапа. Подходит для логотипов, иконок, графиков и диаграмм.
WebP (2010). Механизм: режим с потерями заимствует внутрикадровое предсказание из видеокодека VP8, а режим без потерь использует пространственное предсказание плюс обратные ссылки в стиле LZ77. Сильные стороны: оба режима в одном формате, альфа-канал в режиме с потерями, анимация и файлы на 25–34% меньше JPEG при сопоставимом качестве по данным собственного исследования Google. Слабые стороны: жёсткий предел в 16383 × 16383 пикселя и кодировщик, потребляющий больше CPU, чем libjpeg. Подходит почти для всего, поэтому именно он стал стандартным путём апгрейда с JPEG, PNG и GIF в вебе.
AVIF (2019). Механизм: статичные кадры видеокодека AV1, завёрнутые в контейнер HEIF. Сильные стороны: лучшее сжатие с потерями из доступных в браузере, примерно на 50% меньше JPEG при сопоставимом качестве по результатам тестирования Netflix 2020 года, плюс 10-битный и 12-битный цвет, HDR, альфа-канал и анимация. Слабые стороны: кодирование по-настоящему медленное, нет прогрессивного рендеринга (изображение появляется целиком или не появляется вообще), а очень низкие настройки качества размазывают текстуру так, как честная блочность JPEG не размазывает. Подходит для фотографий и hero-изображений, где размер файла важнее всего.
HEIC (2015). Механизм: статичные кадры HEVC, тоже в контейнере HEIF. Сильные стороны: сжатие уровня AV1 и статус формата съёмки по умолчанию на каждом iPhone с 2017 года. Слабость юридическая, а не техническая: HEVC опутан патентными пулами, и все производители браузеров, кроме Apple, платить отказались. Ему место в фотогалереях телефонов, а не в вебе.
JPEG XL (2021). Механизм: два движка под одной крышей, VarDCT для работы с потерями и модульный режим для сжатия без потерь, плюс трюк, которого нет ни у одного другого формата. Он умеет без потерь пересжимать существующий JPEG примерно до 80% его исходного размера, с побитово точными пикселями. Сильные стороны: прогрессивное декодирование, отличные коэффициенты сжатия без потерь, фотография высокой точности. Слабость это принятие рынком, и это в основном история про браузерную политику, о которой рассказано ниже. Подходит для фотографических конвейеров и архивов, а на устройствах Apple и для веба.
Поддержка браузерами, середина 2026 года
Версии, в которых каждый формат включился по умолчанию, по данным caniuse:
| Формат | Chrome | Edge | Firefox | Safari |
|---|---|---|---|---|
| WebP | 32 (янв 2014) | 18 (ноя 2018) | 65 (янв 2019) | 14 (сен 2020) |
| AVIF | 85 (авг 2020) | 121 (янв 2024) | 93 (окт 2021) | 16.4 (мар 2023) |
| JPEG XL | 145, за флагом (фев 2026) | нет | за флагом | 17 (сен 2023) |
| HEIC | нет | нет | нет | 17 (сен 2023) |
На три детали в этой таблице стоит обратить внимание. AVIF на iOS формально появился в Safari 16.0, но без анимации; полная поддержка и на macOS, и на iOS пришла в 16.4. Edge получил AVIF на годы позже Chrome, хотя Edge это Chromium: Microsoft держала декодер выключенным дольше Google. А строка JPEG XL скрывает необычную историю, которой посвящён отдельный раздел ниже.
Глобальный охват по данным caniuse за 2026 год: WebP держится около 97%, AVIF около 93–94%. JPEG и PNG фактически на 100%, и это вряд ли изменится.
Иерархия совместимости
Разложите форматы по охвату, и получится пять уровней.
Первый уровень это универсальный набор: JPEG, PNG, GIF и SVG. Они декодируются в каждом браузере, каждом почтовом клиенте, каждой панели предпросмотра ОС и каждом киоске десятилетней давности. Если файл безусловно обязан открыться, он отдаётся в одном из этих четырёх.
Второй уровень это WebP, в одиночестве. Последним из крупных браузеров держался Safari, и Safari 14 закрыл этот разрыв в сентябре 2020 года. Что осталось, так это установки Internet Explorer и древние Android WebView. Для сайта, в отличие от письма, WebP уже лет пять как безопасный выбор по умолчанию.
Третий уровень это AVIF. Chrome получил его в 2020 году, Firefox в 2021-м, Safari в 2022-м (полная поддержка в марте 2023 года с 16.4), а Edge включил его по умолчанию в январе 2024 года. С начала 2024 года каждый крупный движок декодирует AVIF из коробки. Оставшиеся несколько процентов это старые iPhone и неуправляемые парки Windows, и именно для этого существуют запасные варианты.
Четвёртый уровень это JPEG XL, застрявший. Apple поставляет его нативно с Safari 17 в сентябре 2023 года. Google удалила экспериментальный декодер из Chromium в конце 2022 года, и это вступило в силу с Chrome 110 в феврале 2023 года, а затем развернулась и влила декодер на Rust (jxl-rs), который вышел в Chrome 145 в феврале 2026 года, по-прежнему за флагом. В Firefox декодер годами существует за флагом. Так что поддержка JPEG XL в середине 2026 года означает всех пользователей Apple плюс исчезающую долю пользователей Chrome и Firefox, которые переключают флаги: группу слишком маленькую, чтобы на неё опираться.
Пятый уровень это HEIC: Safari 17 на платформах Apple и больше нигде. Это даже не уровень, а экосистема одного производителя.
Что веб реально отдаёт
Поддержка это не использование. Web Almanac от HTTP Archive обходит миллионы реальных страниц и считает, что они отдают, и выпуск 2024 года (последний с полными данными по медиа) читается как движение ледника. JPEG всё ещё был самым распространённым форматом с 32% всех изображений, но это на восемь полных пунктов ниже 40% в 2022 году. WebP подобрал три из этих пунктов и достиг 12%. SVG прибавил около двух. AVIF достиг примерно 1%, что звучит как погрешность округления, пока не прочитаешь это в относительных числах: почти четырёхкратный рост за два года. ICO держал 1,3%, и почти весь это фавиконки. А GIF, в свои 37 лет, каким-то образом прибавил пункт.
Почему всё движется так медленно? Основную работу делают три причины. Кеширование на CDN: изображения лежат на периферии, привязанные к URL, а смена форматов означает инвалидацию кешей и перекодирование целых библиотек. Старые устройства: график поддержки говорит 97%, но недостающие 3% сконцентрированы в дешёвых Android-смартфонах и корпоративных парках, и некоторые сайты не могут позволить себе потерять ни одной продажи из-за сломанной картинки. Инерция инструментов: CMS генерирует миниатюры JPEG, потому что всегда генерировала, дизайн-инструмент экспортирует PNG, потому что это большая кнопка, а смена умолчания означает трогать сборочный конвейер, которым никто не владеет.
Есть ещё стоимость кодирования. Преимущество AVIF в сжатии оплачивается процессорным временем в момент кодирования, поэтому имидж-CDN берут за него деньги, а умные команды генерируют AVIF заранее, при сборке или загрузке, а не на лету.
Куда всё движется
AVIF самая надёжная ставка на ближайшие несколько лет. Он свободен от роялти по замыслу (Alliance for Open Media был основан в 2015 году компаниями Amazon, Cisco, Google, Intel, Microsoft, Mozilla и Netflix именно ради побега от патентных пулов в стиле HEVC), он покрывает сжатие с потерями и без в одной спецификации, он несёт HDR, и он пересёк порог поддержки, за которым цепочка запасных вариантов стоит почти ничего. Реальные издержки это время кодирования и отсутствие прогрессивного декодирования. Первое решается предварительной генерацией, второе это приемлемый компромисс.
JPEG XL заслуживал лучшей судьбы, чем ему выпала. По техническим достоинствам это самый полный формат из когда-либо стандартизированных: прогрессивное декодирование, лучший режим без потерь, фотография с высокой битовой глубиной и пересжатие без потерь всего существующего корпуса JPEG. Google вытащила его из Chromium, сославшись на недостаточный интерес экосистемы, и запрос на возвращение стал одним из самых отмеченных звёздами тикетов в истории трекера Chromium. Три года спустя Google пересмотрела решение, но к тому моменту окно для принятия формата уже в основном закрылось. Пока JPEG XL сидел в изгнании, AVIF собрал интеграции CDN, плагины для CMS и галочки по умолчанию. JPEG XL будет жить как любимец архивистов и полноправный гражданин на устройствах Apple. У него были все технические основания стать массовым форматом, но он этот шанс упустил.
HEIC веб-форматом не станет. Причина не имеет отношения к качеству. Декодирование HEVC требует патентных лицензий, за которые производители бесплатных браузеров отказываются платить уже десятилетие, а веб работает на технологиях, свободных от роялти. Формат, который три из четырёх крупных движков декодировать не будут, это не веб-формат; это проблема экспорта, которую вы решаете на границе.
Техника перехода тем временем полностью устоялась и существует в двух формах. Серверное согласование контента: браузер отправляет заголовок Accept со списком того, что умеет декодировать, а сервер или CDN выбирает лучший вариант для того же URL. Клиентский вариант: элемент <picture>, который перечисляет кандидатов и позволяет браузеру взять первый понятный ему:
<picture>
<source srcset="hero.avif" type="image/avif" />
<source srcset="hero.webp" type="image/webp" />
<img src="hero.jpg" alt="Team photo" width="1600" height="900" />
</picture>
<img> внизу это универсальный запасной вариант, поэтому ничего нигде не ломается. Так вы отдаёте AVIF 93% аудитории и JPEG остальным, не поддерживая два сайта.
Таблица решений
| Задача | Что отдавать | Почему |
|---|---|---|
| Фотографии | AVIF, с запасными вариантами WebP и JPEG | Именно на фотографиях экономия байтов наибольшая |
| Скриншоты, снимки UI | PNG или WebP без потерь | Текст и резкие края должны остаться попиксельно точными |
| Логотипы и иконки | SVG, с запасным вариантом PNG | Векторы масштабируются под любую плотность; растрируйте в последнюю очередь |
| Короткие анимации на странице | Сначала видео (MP4/WebM), GIF только ради максимального охвата | Анимированные WebP и AVIF работают в браузерах, но видео сжимает гораздо лучше |
| Фавиконки | ICO для максимального охвата, PNG или SVG для современных браузеров | ICO это контейнер, способный хранить кадры PNG |
Короткая заметка про фавиконки: строка таблицы не вмещает всех деталей. Современные браузеры принимают фавиконки PNG и даже SVG, но ICO остаётся единственным форматом, который понимает каждый краулер, RSS-ридер и древняя вкладка браузера, а файл ICO может упаковать несколько размеров в один контейнер. Если ваш логотип сейчас живёт в другом формате, JPG в ICO, WebP в ICO и PNG в ICO создадут правильный ICO с несколькими размерами прямо в вашем браузере.
Конвертация между форматами
Большинство задач конвертации вытекает из разделов выше. Самая частая, с большим отрывом, это перевести HEIC из iPhone во что-то, что остальной мир способен открыть. HEIC в JPG правильный выбор для обмена, поскольку HEIC уже с потерями, а JPEG не даёт ущербу накапливаться. HEIC в PNG замораживает текущее состояние для редактирования, а HEIC в WebP имеет смысл, когда пункт назначения это сайт.
Дальше идёт треугольник JPEG, PNG, WebP. Перенос JPEG в дизайн-процесс: JPG в PNG, не потому что качество вырастет (оно не вырастет), а потому что оно перестанет падать. Уменьшение для веба: JPG в WebP. В обратную сторону для старого софта: WebP в JPG и WebP в PNG. Скриншот PNG, направляющийся в фотогалерею: PNG в JPG или PNG в WebP, когда нужны файлы поменьше с сохранением прозрачности. Если вам достались несжатые сканы BMP, BMP в JPG, BMP в PNG и BMP в WebP в любом случае лучше, чем рассылать многомегабайтные реликты по почте. Даже документы упираются в ту же развилку: PDF в JPG для фотографических страниц, PDF в PNG, когда текст должен остаться чётким, и PDF в WebP, когда страница направляется в веб.
Каждый из этих инструментов выполняет конвертацию локально в вашем браузере, так что файл не покидает устройство.
Форматы меняются. Правило нет: подбирайте кодек под содержимое и конвертируйте, когда содержимое меняет задачу.
