Conversor JPG/PNG ↔ WebP

Em 2010, o Google anunciou o WebP — um novo formato de imagem derivado diretamente do codec de vídeo VP8, que a empresa havia adquirido junto com a On2 Technologies por 124 milhões de dólares. A lógica era simples: se a compressão de vídeo usava intra-quadros (I-frames) extremamente eficientes, por que não aplicar o mesmo princípio a imagens estáticas? O resultado foi um formato capaz de produzir arquivos 25% a 35% menores que JPEG em fotografias e cerca de 26% menores que PNG em imagens com transparência, com suporte a compressão com perdas (baseada no VP8) e sem perdas (baseada no VP8L), além de animações — tudo num único container. A motivação do Google era pragmática: YouTube, Google Imagens e Google Play servem bilhões de imagens por dia. Uma redução de 30% no tamanho médio significa economia massiva de banda, CDN e latência para usuários.

Apesar do lançamento em 2010, o WebP levou mais de uma década para ser suportado universalmente. O Firefox só adicionou suporte em 2019, o Safari apenas em 2020 com o Safari 14 — mais de dez anos depois do formato existir. Essa lentidão de adoção é uma das razões pelas quais a web ainda está repleta de JPEGs e PNGs. Hoje o WebP é relevante principalmente por causa dos Core Web Vitals do Google: o LCP (Largest Contentful Paint) mede o tempo até a maior imagem visível carregar, e imagens mais leves carregam mais rápido. Sites que migram imagens para WebP frequentemente ganham pontos no PageSpeed Insights. A geração seguinte já chegou: o AVIF (baseado no codec AV1, de 2019) comprime ainda melhor que o WebP, mas é mais lento para codificar e a compatibilidade ainda não é universal.

Nesta ferramenta, JPEG e PNG são decodificados num canvas HTML5 e reexportados para o formato escolhido. A codificação WebP depende do suporte do navegador ao canvas — Chrome, Edge e Firefox modernos funcionam bem. Se você tem um WebP e precisa de um PNG ou JPEG para compatibilidade com sistemas legados, editores de imagem antigos ou clientes de e-mail, o processo inverso também está aqui. Nenhum arquivo é enviado ao servidor.

In 2010, Google announced WebP — a new image format derived directly from the VP8 video codec, which the company had acquired along with On2 Technologies for 124 million dollars. The logic was straightforward: if video compression used extremely efficient intra-frames (I-frames), why not apply the same principle to static images? The result was a format capable of producing files 25% to 35% smaller than JPEG for photographs and about 26% smaller than PNG for images with transparency, with support for both lossy (VP8-based) and lossless (VP8L-based) compression, plus animations — all in a single container. Google's motivation was pragmatic: YouTube, Google Images, and Google Play serve billions of images per day. A 30% reduction in average file size means massive savings in bandwidth, CDN costs, and latency for users.

Despite launching in 2010, WebP took more than a decade to gain universal browser support. Firefox only added support in 2019, and Safari did not until 2020 with Safari 14 — over ten years after the format existed. That slow adoption is one reason the web is still full of JPEGs and PNGs. Today WebP matters primarily because of Google's Core Web Vitals: LCP (Largest Contentful Paint) measures how long it takes for the largest visible image to load, and lighter images load faster. Sites that migrate to WebP often gain points in PageSpeed Insights. The next generation has already arrived: AVIF (based on the AV1 codec, 2019) compresses even better than WebP but encodes more slowly and compatibility is still not universal.

In this tool, JPEG and PNG are decoded on an HTML5 canvas and re-exported to the chosen format. WebP encoding depends on the browser's canvas support — modern Chrome, Edge, and Firefox work well. If you have a WebP file and need a PNG or JPEG for compatibility with legacy systems, older image editors, or email clients, the reverse conversion is here too. No files are uploaded to any server.

En 2010, Google anunció WebP — un nuevo formato de imagen derivado directamente del codec de vídeo VP8, que la empresa había adquirido junto con On2 Technologies por 124 millones de dólares. La lógica era sencilla: si la compresión de vídeo utilizaba intra-fotogramas (I-frames) extremadamente eficientes, ¿por qué no aplicar el mismo principio a las imágenes estáticas? El resultado fue un formato capaz de producir archivos un 25% a 35% más pequeños que JPEG en fotografías y aproximadamente un 26% más pequeños que PNG en imágenes con transparencia, con soporte para compresión con pérdidas (basada en VP8) y sin pérdidas (basada en VP8L), más animaciones — todo en un único contenedor. La motivación de Google era pragmática: YouTube, Google Imágenes y Google Play sirven miles de millones de imágenes al día. Una reducción del 30% en el tamaño medio supone un ahorro masivo de ancho de banda, costes de CDN y latencia para los usuarios.

A pesar de su lanzamiento en 2010, WebP tardó más de una década en recibir soporte universal en los navegadores. Firefox solo añadió soporte en 2019, y Safari no lo hizo hasta 2020 con Safari 14 — más de diez años después de que existiera el formato. Esa lenta adopción es una de las razones por las que la web sigue llena de JPEGs y PNGs. Hoy el WebP importa principalmente por los Core Web Vitals de Google: el LCP (Largest Contentful Paint) mide cuánto tarda en cargar la imagen visible más grande, y las imágenes más ligeras cargan más rápido. Los sitios que migran a WebP suelen ganar puntos en PageSpeed Insights. La próxima generación ya ha llegado: el AVIF (basado en el codec AV1, de 2019) comprime aún mejor que WebP, pero codifica más lentamente y la compatibilidad todavía no es universal.

En esta herramienta, JPEG y PNG se decodifican en un canvas HTML5 y se reexportan al formato elegido. La codificación WebP depende del soporte del canvas del navegador — Chrome, Edge y Firefox modernos funcionan bien. Si tienes un archivo WebP y necesitas un PNG o JPEG por compatibilidad con sistemas heredados, editores de imagen antiguos o clientes de correo electrónico, la conversión inversa también está aquí. Ningún archivo se envía al servidor.