Конвертер AVIF в WebP онлайн

Зачем AVIF превращать в WebP

WebP до сих пор принимают больше CMS, CDN-правил и «простых» <img> без picture. Если AVIF отвергают, WebP — компромисс между весом и совместимостью, лучше чем сразу падать в JPEG на графике с прозрачностью.

Как сделать WebP

Загрузите AVIF, выберите качество или lossless для графики, скачайте .webp. Encode быстрее, чем обратный путь в AVIF, но декод исходника всё равно зависит от размера кадра.

Fallback в picture

Частый паттерн: AVIF первым source, WebP вторым, JPEG третьим. Эта страница готовит средний слой. Не ждите, что WebP будет легче исходного AVIF — часто наоборот, и это нормально для fallback.

Alpha

Прозрачность по возможности сохраняется. Для логотипов включите lossless WebP, если видите кашу на краях при lossy.

Качество WebP

Для фото-fallback начните с 80%. Для UI — lossless. Сравнивать нужно с тем, как выглядит исходный AVIF на том же экране, а не с абстрактным процентом экономии.

Когда оставить AVIF как есть

Если вся аудитория на свежих браузерах и CDN отдаёт AVIF корректно, лишний encode не нужен. Конвертируйте точечно под системы, которые файл не принимают.

Средний слой в picture

Браузер берёт первый source, который понимает. Старый клиент без AVIF, но с WebP, получит этот файл. Поэтому качество WebP не должно быть «отвратительным ради веса»: fallback видят живые люди, не только боты.

JPEG третьим слоем закрывает совсем древние клиенты. Готовьте его отдельно, с фоном, если была прозрачность.

Бюджет страницы

Три файла на одно изображение увеличивают хранение. Имеет смысл на hero и листинге, сомнительно на десятке декоративных иконок. Иконки чаще оставьте SVG или одним PNG/WebP.

Lossless WebP из AVIF-графики проверяйте на краях букв. Lossy 80% — для фото-fallback. Не смешивайте профили в одной папке без правила в README команды.

Практические прогоны AVIF → WebP

CMS принимает WebP, но не AVIF: вот ваш мост. Picture уже есть, нужен средний source: готовьте WebP не хуже, чем витринный AVIF, иначе «старые» пользователи увидят худшую картинку. Иконки: чаще lossless WebP, не lossy 60%.

Сравните вес: если WebP тяжелее AVIF на 30% — это плата за совместимость, не провал. Если тяжелее в разы при том же разрешении, снизьте сторону или проверьте, не включён ли фактически слишком высокий quality.

Не заменяйте AVIF на WebP в папке один-в-один без правила fallback. Иначе свежие браузеры потеряют более плотный файл. Документируйте в команде, какой слой для кого.

Проверка качества: откройте AVIF и WebP рядом на одном экране, 100% зум на лице, небе и мелком тексте. Если WebP заметно хуже — поднимите quality или оставьте AVIF без среднего слоя для этой витрины. Не гонитесь за килобайтом ценой читаемости fallback-аудитории.

Зачем делать WebP из уже готового AVIF

Свежие браузеры берут AVIF. Клиенты без AV1, но с WebP, должны получить средний source, а не сразу тяжёлый JPEG. Эта страница готовит именно его. Она не обязана выиграть у исходного AVIF по весу: часто проиграет, и это плата за совместимость.

Если вся аудитория уже на AVIF и CDN отдаёт его корректно, лишний encode не нужен. Конвертируйте точечно под системы и слои picture, которые файл не принимают.

Админка с WebP и без AVIF

Частый кейс: медиабиблиотека пускает .webp и режет .avif. Тогда WebP — рабочий формат витрины, пока не обновят стек. Не кладите AVIF в такую CMS «через переименование»: получите битый MIME.

После появления поддержки AVIF можно вернуть плотный файл и оставить WebP fallback. Имена парные: hero.avif, hero.webp.

Люди на fallback — не боты

Старый WebView, корпоративный браузер, часть встроенных WebView приложений увидят WebP. Quality 60% «ради килобайта» накажет именно их. Для фото-fallback старт около 80%. Сравнивайте рядом с исходным AVIF на одном экране: лицо, небо, мелкий текст.

Если WebP заметно хуже — поднимите quality или для этой витрины не делайте средний слой и оставьте JPEG третьим, но достойным.

Логотипы: lossless WebP, не грубый lossy

Прозрачность по возможности сохраняется. На контуре буквы lossy 70% часто даёт кашу. Включайте lossless для UI, который пришёл из AVIF-графики. Фото-баннер с мягкой alpha — lossy с проверкой тени на двух фонах.

Как читать «стало тяжелее»

Если WebP на 20–40% тяжелее AVIF при той же стороне — это ожидаемо для fallback. Если в разы — проверьте, не завышен ли quality и не забыли ли ресайз. Не гонитесь за тем, чтобы WebP был легче AVIF: тогда вы скорее убьёте картинку.

Порядок в picture

Браузер берёт первый понятный source. Не ставьте WebP выше AVIF, если AVIF у вас лучше: свежие клиенты тогда не получат плотный файл. JPEG третьим — для совсем древних; готовьте его отдельно, с фоном, если была прозрачность.

Мелкий UI не стоит тройного стека

Иконка 24–48px: накладные расходы трёх форматов выше выигрыша. Оставьте SVG или один WebP. Тройной picture имеет смысл на hero и карточках каталога, не на десятке декоративных галочек.

Чеклист AVIF → WebP

• Понятно, зачем средний слой (CMS или picture), а не «на всякий случай».
• Fallback сверен глазом с AVIF, не только по KB.
• Графика — lossless, фото — ~80% как старт.
• AVIF у свежей аудитории не удалён.
• Имена парные, кэш предсказуем.

Совсем без AVIF-стека: AVIF → JPG. Хаб: конвертер WebP.

Когда CDN сам выбирает формат

Если CDN режет AVIF по User-Agent и отдаёт JPEG, средний WebP может быть выгоднее третьего JPEG: легче и с alpha. Если CDN уже отдаёт AVIF тем, кто умеет, кладите WebP как запасной объект с предсказуемым именем, не как замену.

Кэш двух расширений удваивает ключи. Это нормально на hero. На сотне мелких декоративных файлов посчитайте хранение.

Сверяйте главный баннер, не случайную иконку

Иконка врёт: контейнер и мелкий растр не показывают, как поведёт себя 1600px небо. Откройте AVIF и WebP рядом, 100% зум на лице, градиенте, ценнике. Только после этого тиражируйте профиль на каталог.

Запишите, какой слой для кого

Иначе через месяц кто-то удалит AVIF «раз есть webp» или наоборот выкинет WebP. Короткое правило в README: avif — современные, webp — запас, jpg — древние и почта. Без правила стек разъедется.

Приложение со встроенным браузером

Часть WebView знает WebP и не знает AVIF. Именно для них средний слой. Quality не унижайте: это живые пользователи приложения, не «устаревшие 2% статистики», если приложение — ваш основной канал.

Грубое правило поддержки

Свежий Chrome/Safari/Edge — AVIF. Широкий веб последних лет — WebP. Древние клиенты и почта — JPEG. Средний слой этой страницы закрывает вторую строку. Не ставьте WebP первым source, если AVIF у вас лучше: свежие клиенты тогда не возьмут плотный файл.

Прозрачность стоит байт, но JPEG её не спасёт

Если нужен fallback с дырками, WebP — правильный средний слой, JPEG — нет. Для логотипа включите lossless, даже если фото-баннеры у вас lossy 80%. Смешивать профили в одной папке без правила — путь к «почему буква сыпется только на запасном формате».

Не переименовывайте .avif в .webp

Байт — другой. CMS, которая смотрит на расширение, покажет битую картинку. Эта страница как раз делает настоящий WebP. Имена парные, MIME совпадает с расширением.

Пилот на hero, затем каталог

Неделя с picture на главном баннере покажет реальные User-Agent и жалобы. Только потом тиражируйте профиль. Иконки в этот пилот не тащите. Запишите quality, которым закрыли баннер: следующий сезон не должен гадать.

Кэш, который отдаёт старый AVIF под новым именем WebP

Если вы положили hero.webp, а CDN неделю держит старый объект, пользователи увидят кашу или 404. Меняйте query или версию в имени при первой выкладке среднего слоя. Не надейтесь, что «расширение другое — ключ другой» на всех конфигурациях: часть правил кэширует без расширения.

Письмо всё равно не про WebP

Средний слой picture — для сайта. Вложение в рассылку чаще JPEG, иногда PNG. Не отправляйте клиенту hero.webp «потому что мы только что его сделали из AVIF». Канал другой, формат другой.

Если CMS перекодирует загруженный WebP ещё раз своим плагином, вы получите третий lossy. Либо отключите плагин для уже готовых файлов, либо грузите мастер и пусть CMS сама строит производные. Два автоматических encode подряд портят небо и мелкий текст быстрее, чем кажется по весу.

На слабом канале первый WebP из AVIF подождёт декод AV1 и загрузку энкодера WebP. Пачка после прогрева идёт ровнее. Не открывайте параллельно PNG→AVIF в другой вкладке: оба кодека тяжёлые.

Как смотреть результат, чтобы не обмануть себя

Превью ОС уменьшает кадр и прячет кашу. Откройте оба файла в браузере на 100% зуме, на том мониторе, на котором смотрит заказчик, если можете. Ночной OLED и офисный TN по-разному показывают градиент неба: то, что «сойдёт» на одном, на другом станет пятном.

Не верьте только колонке килобайт. Fallback, который легче AVIF на 5% и заметно хуже по лицам, — плохая сделка. Лучше WebP на 15% тяжелее и спокойная картинка для тех, кто AVIF не умеет.

Короткий итог AVIF → WebP

Средний слой picture и CMS без AVIF. Fallback должен выглядеть достойно. WebP может быть тяжелее — это плата за совместимость. Lossless для графики, около 80% для фото. Не удаляйте AVIF у свежей аудитории. Сверяйте два файла рядом на 100% зуме, прежде чем катить на всю витрину. Иконки чаще оставьте одним WebP, без лишнего AVIF-слоя.