# Google traz JPEG XL de volta ao Chrome

Published: 2026-10-07

O Google anunciou a decodificação de JPEG XL a partir do Chrome 155, depois que seu experimento anterior foi removido. Esta edição de 7 de outubro examina o feedback dos desenvolvedores, o novo decodificador Rust, as alegações de compressão concorrentes e os "fallbacks" de implantação, e então analisa os novos artefatos de prova matemática publicados pela OpenAI e o design de "hash-in-flash" de um "sinkhole" DNS ESP32-C3.

Canonical: https://thedailydiff.dev/pt-BR/video/chrome-jpeg-xl-comeback/

## O que este vídeo aborda

- O anúncio do Chrome foi publicado em 6 de outubro de 2026 e menciona o Chrome 155. Ele não estabelece que todo visitante do site já use uma versão suportada.
- O Google atribui o mérito ao feedback persistente dos desenvolvedores e ao processo Interop. O decodificador jxl-rs usa Rust e operações vetoriais otimizadas, enquanto pequenas áreas inseguras verificadas e a "sandbox" do navegador permanecem.
- A melhoria de compressão anunciada pelo Google, de 30-50%, usa JPEG como base. As economias reais dependem das imagens, configurações do codificador e qualidade visual.
- A comparação de codificadores de setembro de Gianni Rosato favorece o AVIF em sua faixa de fidelidade "lossy" testada. Ele desenvolve ferramentas AVIF concorrentes; seu resultado e a afirmação de base JPEG do Google medem comparações diferentes.
- Compare os formatos em imagens representativas e mantenha "fallbacks" compatíveis. JPEG XL também suporta transcodificação reversível e sem perdas de arquivos JPEG existentes.
- A OpenAI lançou 722 manuscritos agrupados em 372 famílias, com verificação variada e muitas formalizações Lean. O modelo permanece inédito, e os números de computação equivalentes ao Pro não são um preço de varejo nem uma garantia de tempo decorrido.
- O criador do ESP32-C3 relata aproximadamente 50 KB de uso de RAM ao armazenar hashes de domínio ordenados na "flash". O bloqueio em nível de DNS tem limitações de mesmo domínio e "resolvers" alternativos; colisões de "hash" podem bloquear excessivamente. Os resultados de hardware não foram medidos independentemente para este episódio.

## Capítulos

- 0:00 Por que o Chrome está trazendo o JPEG XL de volta?
- 0:33 Por que o formato rejeitado teve outra chance?
- 1:01 O que mudou dentro do decodificador?
- 1:47 Os arquivos menores superam o AVIF?
- 2:56 O que a OpenAI realmente publicou?
- 4:03 Como uma placa de dois dólares bloqueia domínios?
- 4:38 Seus JPEGs existentes podem participar do retorno?
- 4:58 Por que eu enviaria o decodificador e testaria a migração?

## Transcrição traduzida

Traduzido da narração original em inglês. Áudio e legendas disponíveis são controlados pelo YouTube.

### Por que o Chrome está trazendo o JPEG XL de volta?

0:00 Você provavelmente pensa que o Google enterrou o JPEG XL. O Chrome está trazendo-o de volta, depois de remover o suporte experimental, e o Rust ajudou-o a entrar pela porta. Neste vídeo, por que o Google reverteu o curso? E você deve mudar seu "pipeline" de imagens? É quarta-feira, sete de outubro, e este é o The Daily Diff. Mantenha um detalhe em mente. Seus JPEGs existentes têm um caminho para este retorno.

0:20 Na terça-feira, o Google anunciou a decodificação de JPEG XL a partir do Chrome cento e cinquenta e cinco. Hoje, o anúncio subiu no Hacker News, junto com o despejo de provas matemáticas da OpenAI e uma placa de dois dólares que bloqueia domínios de publicidade. O experimento anterior do Chrome terminou em vinte e vinte e três.

### Por que o formato rejeitado teve outra chance?

0:35 A explicação do Google incluiu interesse insuficiente do ecossistema, o que é estranho quando o maior navegador controla se o ecossistema pode realmente usar sua coisa. A nova postagem credita o feedback persistente dos desenvolvedores, incluindo o processo Interop. As pessoas que pediam por isso continuaram pedindo, e o Google agora aponta para testes de navegador destinados a fazer com que o formato se comporte de forma consistente. O anúncio credita colaboradores incluindo Helmut Januschka.

0:57 Às vezes, o "roadmap" mais eficaz é recusar-se a fechar a questão.

### O que mudou dentro do decodificador?

1:01 A maior mudança de implementação é um decodificador chamado jay ex ell R S, escrito em Rust. Decodificadores de imagem ingerem arquivos complicados fornecidos por estranhos, o que os torna um lugar espetacular para acidentalmente confiar na internet. O Rust ajuda a prevenir classes de erros de memória antes que se tornem vulnerabilidades do navegador. O Google ainda mantém a "sandbox", e a implementação ainda contém pequenas áreas inseguras cuidadosamente revisadas. A segurança tem camadas, porque a realidade continua encontrando as brechas.

1:27 O Google diz que "fuzzing" e revisão de código por IA não encontraram bugs de segurança de memória na história deste decodificador. Isso é um relatório útil da equipe que o está enviando. Futuros atacantes são improváveis de aceitar a postagem do blog como um contrato vinculativo. Primeira pergunta respondida. A pressão dos desenvolvedores e um decodificador Rust otimizado reabriram a porta. O Google reverteu uma decisão com engenharia por trás dela, o que é permitido até na internet. Agora, os benchmarks da apresentação.

### Os arquivos menores superam o AVIF?

1:48 O Google anuncia trinta a cinquenta por cento melhor compressão que o JPEG. Downloads menores podem ajudar seus usuários e sua conta de largura de banda, mas essa faixa depende do que você codifica e como você compara a qualidade. O engenheiro de compressão Gianni Rosato publicou uma comparação em setembro onde os "encoders" modernos avif superaram o JPEG XL em sua faixa de fidelidade testada. Ele trabalha em ferramentas avif concorrentes, então mantenha esse incentivo ao lado dos gráficos. Essas comparações usam "baselines" diferentes.

2:12 Superar o JPEG antigo deixa espaço para o avif vencer uma carga de trabalho. O próprio Google recomenda experimentar ambos os formatos, o que é um conselho incomumente prático para um anúncio de lançamento. Outras atrações do JPEG XL incluem alta faixa dinâmica, imagens sem perdas e decodificação progressiva granular. A comunidade publica demos interativas para explorar o formato. Sua audiência pode ver uma imagem útil enquanto o restante chega. Para implantação, mantenha uma imagem "fallback" e verifique o suporte nos navegadores que seus

2:37 clientes realmente usam. O anúncio menciona o Chrome cento e cinquenta e cinco. Isso lhe dá uma versão alvo, e sua análise informa quando sua audiência chega lá. Segunda pergunta respondida. Teste suas imagens reais antes de mudar o "pipeline" e preserve o caminho de compatibilidade. Um formato de imagem que economiza bytes é útil. Uma migração que oculta seu botão de finalização de compra é uma interpretação cara do minimalismo. Enquanto isso, a OpenAI publicou manuscritos matemáticos e artefatos de prova

### O que a OpenAI realmente publicou?

3:00 de suporte na terça-feira. O repositório contém setecentos e vinte e dois manuscritos, agrupados em famílias relacionadas. A contagem principal inclui argumentos complementares e provas alternativas, então leia o que cada artigo realmente afirma. Muitos têm provas formais em Lean, o que permite que um computador verifique deduções matemáticas. Outros ainda aguardam formalização, e a OpenAI avisa explicitamente que

3:21 alguns resultados não formalizados podem ter problemas. O repositório entrega aos pesquisadores material que eles podem inspecionar e desafiar. O modelo permanece inédito. A OpenAI diz que cada resultado usou aproximadamente três horas de computação de "thinking" equivalente ao ChatGPT Pro em média. Isso descreve o esforço computacional. Isso não lhe dá uma garantia de "wall clock" nem um preço de varejo para produzir um

3:40 teorema. O lançamento segue consulta com um grupo consultivo de matemática independente, e inclui um processo de revisão e citação. A academia recebe uma nova pilha de lição de casa, além da capacidade muito mais útil de apontar para a página exata que precisa de correção. Os mantenedores do Lean recomendam compilar pequenas porções por vez. Mesmo uma descoberta matemática eventualmente encontra o antigo inimigo do software, fazer a construção terminar.

### Como uma placa de dois dólares bloqueia domínios?

4:03 Finalmente, um bloqueador de anúncios DNS de código aberto roda em uma minúscula placa de microcontrolador de dois dólares. O truque do criador é armazenar "hashes" de domínio classificados na "flash", para que a "blacklist" não precise viver na escassa memória de trabalho. O projeto relata aproximadamente cinquenta kilobytes de uso de RAM. Ele procura um domínio solicitado na tabela "flash", bloqueia uma correspondência e encaminha outras consultas "upstream". Seu roteador pode adquirir um pequeno "bouncer" com uma lista de convidados muito específica. A filtragem de DNS funciona no nível do domínio.

4:28 Anúncios veiculados do mesmo domínio que conteúdo útil podem passar, e clientes que usam outro "resolver" podem ignorá-lo. Mantenha suas expectativas menores que a placa, que é um alvo de tamanho exigente. E o detalhe sobre seus JPEGs existentes?

### Seus JPEGs existentes podem participar do retorno?

4:40 JPEG XL suporta transcodificação JPEG sem perdas, com um caminho para reconstruir o JPEG original. Isso oferece a um arquivo de imagem antigo uma opção de migração sem outra geração de perda de qualidade. Teste as "tradeoffs" de armazenamento e entrega. Se você preferir ler isso a me ouvir dizer, o "diff" chega na sua caixa de entrada todas as manhãs, gratuitamente em the daily diff dot dev, link abaixo.

### Por que eu enviaria o decodificador e testaria a migração?

4:58 Então o veredito de hoje, SHIP IT. Eu enviaria o decodificador adicional porque o suporte do navegador oferece aos desenvolvedores uma escolha real, e eu testaria a migração em nossas próprias imagens. Inscreva-se, clique no sino e me diga nos comentários se você teria carimbado diferente. E esse é o "diff" de hoje. Sou Niko da Axrisi. Mescle com responsabilidade.

## Fontes

- [Shipping JPEG XL in Chrome](https://developer.chrome.com/blog/jpeg-xl-in-chrome) — Chrome for Developers
- [JPEG XL prototype and November 2022 removal discussion](https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKcBw219k) — Chromium Blink developers
- [Contemporaneous JPEG XL deprecation commentary](https://www.fsf.org/blogs/community/googles-decision-to-deprecate-jpeg-xl-emphasizes-the-need-for-browser-choice-and-free-formats) — Free Software Foundation
- [The case against JPEG XL — competing-encoder benchmark](https://giannirosato.com/blog/post/case-against-jxl/) — Gianni Rosato
- [JPEG XL FAQ and reversible JPEG transcoding](https://jpegxl.info/resources/faqs.html) — JPEG XL community
- [HTML picture element and fallback selection](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/picture) — MDN Web Docs
- [Progressive loading demo](https://jpegxl.info/resources/progressive-loading-demo.html) — JPEG XL community
- [Distance versus effort visualizer](https://jpegxl.info/resources/distance-vs-effort-visualizer.html) — JPEG XL community
- [Sharing AI progress in mathematics](https://openai.com/index/sharing-ai-progress-in-mathematics/) — OpenAI
- [Mathematical manuscripts and proof artifacts](https://github.com/openai/math) — OpenAI on GitHub
- [Lean formalization library build notes](https://github.com/openai/math/blob/main/lean/README.md) — OpenAI on GitHub
- [ESP32-C3 hash-in-flash DNS ad blocker](https://github.com/M-Abozaid/esp32-c3-adblock) — M-Abozaid on GitHub