Compressor de imagens gratuito on-line

Como funciona

1. Selecione ou arraste uma ou mais imagens acima.
2. Ajuste o controlo de qualidade (mais baixo = ficheiro mais pequeno, mais compressão).
3. As imagens são comprimidas no seu navegador · nada é enviado.
4. Transfira as imagens comprimidas uma a uma ou todas de uma vez.

Porquê comprimir imagens?

Imagens pesadas tornam os sites mais lentos, aumentam a taxa de rejeição e prejudicam a sua classificação no Google. Comprimir imagens reduz o tamanho do ficheiro em 50-80% com uma perda de qualidade visual mínima. É essencial para programadores web, bloguers, lojas online e qualquer pessoa que publique conteúdo na internet. Imagens mais leves também poupam largura de banda em dispositivos móveis e melhoram as pontuações Core Web Vitals.

O que «compressão de imagem» realmente significa

A compressão de imagem abrange duas operações fundamentalmente diferentes que compartilham um nome. A compressão com perda, usada por JPEG e WebP em modo com perda, descarta dados de imagem que o olho humano dificilmente percebe (graduações sutis em sombras, ruído de alta frequência, subamostragem de croma em relação à luminância para tirar proveito da percepção humana). A saída é menor que a entrada mas não pode ser reconstruída bit a bit. A compressão sem perda, usada por PNG, GIF, TIFF-LZW e WebP sem perda, codifica os dados de pixel exatos de forma mais compacta com algoritmos como DEFLATE (LZ77 + Huffman). A saída é menor e a descompressão reproduz o original byte por byte. Qual delas é a certa depende da imagem: fotografias toleram bem a perda porque seu conteúdo é cheio de textura que o olho não acompanha em nível de pixel; logos, capturas e gráficos com transições nítidas de cor exigem o sem perda porque cada pixel é intencional.

Os ajustes de qualidade em um compressor JPEG (o controle desta ferramenta, de 10 a 100 %) controlam as tabelas de quantização aplicadas depois do passo DCT. Em qualidade 100, as tabelas mal arredondam coeficientes de frequência; em qualidade 50, arredondam de forma agressiva. Maior qualidade significa arquivos maiores com detalhes mais finos; menor qualidade significa arquivos menores com artefatos em blocos visíveis em áreas planas. O padrão de 60 % fica no ponto ideal para uso web: tipicamente uma redução de 50 a 80 % no tamanho do arquivo sem mudança perceptível numa tela típica. Para impressão ou telas grandes, suba para 80-90 %. Para miniaturas ou versões amigáveis para e-mail, 30-50 % funciona bem.

Para PNG, o controle de «qualidade» não se aplica no sentido habitual porque PNG é sempre sem perda. O que esta ferramenta de fato faz numa entrada PNG é rodar uma passagem DEFLATE mais agressiva do que a maioria dos softwares de autoria (Photoshop, Affinity, Sketch) usa por padrão; isso geralmente recorta 5 a 25 % do tamanho do arquivo sem mudar nenhum pixel. O menu Formato também permite converter PNG para JPEG ou WebP, o que troca o sem perda por um arquivo bem menor mas perde a transparência na saída JPEG e (para conteúdo fotográfico) a garantia de sem perda no WebP. A opção Largura Máxima redimensiona as imagens durante a compressão: uma foto de 4000 pixels de largura reduzida a 1920 pixels economiza 75 % na contagem bruta de pixels antes mesmo de qualquer compressão rodar, e isso se soma à redução de qualidade.

Como esta ferramenta funciona por dentro

O motor de compressão é o browser-image-compression de Donald Wong (GitHub: Donaldcwl/browser-image-compression, licença MIT). É uma biblioteca em JavaScript puro, cerca de 95 KB minificada, que envolve três primitivas do navegador: a API File para ler bytes, a API Canvas (ou OffscreenCanvas quando disponível) para decodificar, redimensionar e recodificar imagens JPEG/WebP, e o UZIP (uma pequena biblioteca DEFLATE) para tratar PNG sem passar pelo Canvas. Quando você solta uma imagem, o navegador entrega os bytes para a biblioteca; a biblioteca escolhe o caminho de acordo com o formato de entrada e a saída solicitada.

Para entradas JPEG e WebP, o caminho é: decodificar para um canvas, redimensionar opcionalmente para a Largura Máxima configurada, e então chamar canvas.toBlob(mimeType, qualidade/100). O codificador JPEG ou WebP embutido no navegador faz a quantização e a codificação de Huffman de fato. A qualidade é o valor do seu controle dividido por 100, passado como segundo argumento. Para entradas PNG mantidas como PNG, a biblioteca pula o Canvas inteiramente (uma ida e volta por Canvas re-rasterizaria desnecessariamente os dados sem perda) e em vez disso roda o UZIP sobre os blocos IDAT do arquivo PNG diretamente, com esforço máximo de compressão. É por isso que a compressão PNG para PNG aqui é genuinamente sem perda: os dados de pixel nunca são decodificados e recodificados, só o invólucro DEFLATE é apertado.

Quando OffscreenCanvas é suportado (Chrome, Edge, Safari, Firefox modernos), o trabalho pesado de decodificar-redimensionar-codificar roda dentro de um Web Worker, mantendo a thread principal da interface responsiva. Você pode soltar um lote de 20 fotos e continuar rolando a página enquanto cada uma é processada. Em navegadores mais antigos, a biblioteca cai para a thread principal, que ainda funciona mas trava a página durante tarefas grandes. Todo o pipeline roda dentro da sua aba. A biblioteca é carregada uma vez de um CDN (cerca de 95 KB minificada) na primeira visita e fica em cache depois. Nenhum conteúdo de arquivo deixa o navegador. Abra a aba Rede do DevTools enquanto comprime um lote e você verá o carregamento único da biblioteca e nada mais.

Uma breve história dos formatos de compressão de imagem

• DCT, 1972-1974. Nasir Ahmed propôs a transformada discreta de cosseno como método de compressão de imagem em 1972; o algoritmo formal foi publicado com T. Natarajan e K. R. Rao em 1974. Essa única transformação matemática está debaixo de cada arquivo JPEG, MPEG e H.26x do mundo hoje.
• JPEG, 1992. O Joint Photographic Experts Group (formado em 1986) padronizou o JPEG como ITU-T T.81 / ISO/IEC 10918-1 em 1992. Blocos DCT 8x8, espaço de cor YCbCr com subamostragem de croma opcional, tabelas de quantização ajustadas para a visão humana. O formato que tornou a web rica em fotos possível.
• PNG, 1996. Criado no IETF como RFC 2083 para substituir o GIF depois que as reivindicações de patente LZW da Unisys ameaçaram a web aberta. Compressão DEFLATE (LZ77 + Huffman), sempre sem perda, transparência alfa completa, sem entrave de patente. A 3.ª edição da especificação (W3C, 2023) adicionou HDR, animação APNG e metadados EXIF oficialmente.
• WebP, 2010. O Google lançou o WebP como formato de imagem estática baseado na codificação intra-frame do codec de vídeo VP8. WebP com perda é 25-34 % menor que JPEG em qualidade visual comparável; WebP sem perda é cerca de 26 % menor que PNG. A adoção levou uma década; em 2026 mais de 96 % dos navegadores no mundo o suportam.
• AVIF, 2019. A Alliance for Open Media lançou o AVIF como a variante de imagem estática do codec de vídeo AV1. Cerca de 50 % menor que JPEG em qualidade comparável. O suporte de navegador agora é maior que 95 %, mas o suporte de codificadores nas ferramentas de autoria do dia a dia (Photoshop, Word, Slack) está atrasado. Squoosh e ImageMagick podem produzir AVIF hoje; a maioria das câmeras e telefones não.
• HEIC, 2017. A Apple adotou o HEIC, baseado em HEIF/H.265, como formato de foto padrão do iPhone. Cerca de metade do tamanho do JPEG equivalente. Onerado por royalties, então raramente é servido na web aberta. A maioria dos uploaders online (inclusive esta ferramenta) só aceita HEIC após uma conversão para JPEG no desktop; essa conversão é o fluxo diário para enviar fotos do celular a um destinatário não-Apple.

Formatos suportados

• JPEG · Ideal para fotografias e imagens complexas. Compressão com perdas e qualidade ajustável.
• PNG · Ideal para gráficos, logótipos e imagens com transparência.
• WebP · O formato moderno da Google, com ficheiros mais pequenos que JPEG/PNG para qualidade equivalente.

Fluxos de compressão do mundo real

• Imagens de blog e site. Um JPEG de 2 MB direto do celular contra um JPEG comprimido de 250 KB: idênticos ao olho humano numa tela típica, mas o arquivo menor carrega cerca de 8 vezes mais rápido. Os scores de Core Web Vitals (LCP) melhoram diretamente. A maioria das páginas com várias fotos vê os maiores ganhos de Lighthouse pela compressão de imagens, não pela otimização de JavaScript ou CSS.
• Uploads em redes sociais. Instagram, Twitter, Facebook, LinkedIn todos recomprimem as imagens no upload com seus próprios algoritmos. Comprimir antes dá a você controle sobre o que é sacrificado; subir fotos cruas deixa essas escolhas para a plataforma, frequentemente com degradação visível.
• Anexos de e-mail. A maioria dos provedores limita anexos a 25 MB por mensagem (Gmail, Outlook, Apple Mail). Comprimir uma pasta de fotos de cerca de 50 MB para cerca de 10 MB permite enviar tudo num único e-mail em vez de dividir em vários envios ou ir para um link de compartilhamento em nuvem.
• Fotos de produto de e-commerce. Catálogos de produtos com centenas ou milhares de fotos geram contas altas de banda em CDN e carregamentos lentos de página. Comprimir toda a biblioteca corta os dois. Vendedores de Shopify, Etsy e Amazon comumente comprimem antes do upload para reduzir custos de hospedagem e melhorar o posicionamento em busca.
• Portfólios cheios de capturas de tela. Portfólios de design de interface são pesados em PNG porque capturas de tela têm transições de cor nítidas onde os artefatos JPEG seriam visíveis. PNG para PNG com DEFLATE mais apertado costuma economizar 10-20 % sem mudança de pixel, útil para sites de portfólio de designers que precisam ser rápidos sem sacrificar a qualidade de renderização.
• Redução de arquivos. Uma foto de 12 megapixels de um celular é exagero para um álbum de família que só será visto em telas. Redimensione para 4 megapixels a 80 % de qualidade: o resultado fica idêntico em cada dispositivo que vai vê-lo, e o arquivo encolhe para um quinto do tamanho original. Os originais ficam seguros no disco de origem; as versões comprimidas vão para o compartilhamento ou backup.

Armadilhas comuns e o que significam

• Recomprimir um JPEG várias vezes o degrada. Cada salvamento de JPEG roda novamente o passo de quantização DCT, perdendo detalhes que você nunca vai recuperar. As perdas são sutis na primeira passagem e óbvias na terceira ou quarta. Sempre comprima a partir da fonte de mais alta qualidade que você tem (o arquivo original da câmera, a exportação da sua ferramenta de design), não a partir de um JPEG já comprimido que você salvou na semana passada. Se precisar fazer ajustes, mantenha uma cópia mestre em PNG ou TIFF.
• PNG para JPEG perde a transparência. JPEG simplesmente não tem canal alfa na especificação do formato. Qualquer pixel transparente vira branco sólido (ou o que o codificador substituir) ao converter PNG para JPEG. Para logos, ícones, capturas com fundo transparente ou qualquer gráfico com canal alfa, fique em PNG ou vá para WebP, que preservam a transparência.
• JPEG para PNG aumenta o arquivo. A compressão DEFLATE do PNG é ótima com gradientes suaves e áreas planas grandes, e terrível com os padrões de ruído de alta frequência que a compressão JPEG deixa para trás. Converter um JPEG em PNG frequentemente dobra ou triplica o tamanho do arquivo sem ganho de qualidade. Se você precisa de sem perda a partir de um JPEG, já é tarde: a informação original se foi. A conversão só faz sentido se você precisa especificamente da transparência do PNG ou de uma ferramenta que não aceita JPEG.
• Os metadados EXIF são removidos por padrão. A biblioteca browser-image-compression descarta por padrão os metadados EXIF (informações da câmera, coordenadas GPS, data de captura, perfil de cor ICC) durante a recompressão. Para uso web costuma ser uma virtude (vazar coordenadas GPS é um problema real de privacidade). Para fotógrafos arquivando com metadados intactos, esta ferramenta não é a certa; use um compressor de desktop ciente de EXIF como o ImageOptim ou jpegtran com a opção explícita de «preservar metadados».
• Os perfis de cor podem não sobreviver. Um perfil de cor ICC embutido (sRGB, Adobe RGB, ProPhoto) diz aos monitores como interpretar os valores de pixel. A recodificação baseada em Canvas pode descartar o perfil embutido e marcar a saída como sRGB. Para uso comum em tela tudo bem, porque quase tudo já é sRGB. Para trabalhos de preparação para impressão, preparação de fotos com gerenciamento de cor ou entregas de gama ampla, use uma ferramenta consciente de cor (Exportar Como do Photoshop, Affinity, RawTherapee) que preserve explicitamente os dados de perfil.
• Imagens muito grandes podem travar uma aba móvel. Decodificar uma imagem para Canvas precisa de RAM proporcional às suas dimensões: uma foto de 24 megapixels (6000x4000 pixels) precisa de cerca de 96 MB só para o buffer de pixels RGBA, mais a memória de trabalho do codificador. Dispositivos móveis com 4 GB de RAM podem ter a aba encerrada pelo sistema operacional antes da codificação terminar. Redimensione a entrada ou use um navegador de desktop para fotos muito grandes.

Privacidade: as imagens ficam no seu dispositivo

Todo compressor de imagens em nuvem (TinyPNG, Compressor.io, Optimizilla, as ferramentas de imagem do Smallpdf, o endpoint de compressão do Pixlr, as dezenas de serviços «comprimir imagem online») envia seu arquivo para os servidores do operador, roda o algoritmo de compressão deles e devolve a imagem menor como download. As implicações de privacidade não são triviais porque fotos rotineiramente contêm conteúdo identificável: rostos, endereços visíveis ao fundo, capturas de interfaces internas ou documentos confidenciais, fotos de crianças, fotos tiradas em espaços privados. A maioria dos operadores publica políticas de privacidade comprometendo-se a apagar uploads dentro de uma ou duas horas e a cifrar em trânsito, e os maiores (TinyPNG, Smallpdf) mantêm certificação ISO/IEC 27001. Eles têm motivos comerciais fortes para honrar essas políticas. Mas «apagado em uma hora» não é «nunca visto». Durante essa hora o conteúdo da imagem fica na infraestrutura do operador, acessível a qualquer processo ou pessoa com permissões adequadas, e visível em logs e backups segundo a política de retenção aplicável.

Este compressor nunca envia nada. A biblioteca browser-image-compression roda inteiramente na sua aba; os bytes da imagem são lidos pela API File, processados em JavaScript (ou num Web Worker se OffscreenCanvas estiver disponível), e a saída comprimida é devolvida à mesma aba como um Blob para download. Você pode verificar a ausência de upload abrindo as ferramentas de desenvolvedor do navegador na aba Rede antes de comprimir um lote: nenhuma requisição é disparada com o conteúdo da sua imagem. O único tráfego de rede é o carregamento único da biblioteca (~95 KB) do CDN na primeira visita, depois do qual a biblioteca fica em cache. Coloque o navegador em modo avião depois que a página carregar e o compressor continua funcionando sobre arquivos locais. Para fotos com qualquer coisa sensível (rostos, locais, capturas internas), o trade-off do lado do navegador claramente vale a pena.

Quando outra ferramenta é a escolha certa

• Processar em lote mais de 500 imagens num pipeline com script. Use sharp em Node.js (a biblioteca canônica de imagem do lado servidor), ImageMagick ou GraphicsMagick na linha de comando, ou Pillow em Python. Essas ferramentas lidam com milhares de arquivos sem limites de memória do navegador e rodam a partir de jobs de CI, hooks de deploy ou tarefas cron.
• Garantias rigorosas de sem perda com igualdade de bits verificável. Para PNG para PNG, esta ferramenta é genuinamente sem perda porque o UZIP não toca nos dados de pixel. Para fluxos que exigem verificação criptográfica (imagem médica, prova legal), use uma ferramenta de desktop como ImageMagick com `-define png:compression-level=9` explícito e verificação SHA-256 dos dados de pixel decodificados.
• Preservação de perfil de cor de nível impressão. Adobe Photoshop, Affinity Photo ou RawTherapee para trabalho de pré-impressão com preservação de perfil ICC, prova de tela e saída CMYK. A compressão baseada em navegador não pode garantir fluxos com gerenciamento de cor porque o Canvas opera em sRGB e pode descartar os dados de perfil embutidos.
• Saída AVIF para compressão de próxima geração. O browser-image-compression não produz AVIF em 2026. Para codificação AVIF no navegador, use Squoosh (também do Google, também no cliente); para AVIF na linha de comando, use o avifenc do libavif. AVIF produz arquivos cerca de 50 % menores que JPEG em qualidade comparável, mas o codificador é computacionalmente caro (10 vezes mais lento que codificação JPEG).

Perguntas frequentes

A compressão reduz a qualidade da imagem?

Com a qualidade predefinida de 60%, a maioria das imagens parece quase idêntica ao original, mas fica 50-80% mais pequena. Ajuste o controlo para encontrar o equilíbrio certo para o que precisa.

Existe um limite de tamanho de arquivo?

Cada imagem pode ter até 50 MB. Como o processamento acontece no seu navegador, ficheiros muito grandes podem demorar um pouco, consoante o seu dispositivo.

As minhas imagens são enviadas para um servidor?

Não. Toda a compressão acontece localmente no seu navegador. As suas imagens nunca saem do seu dispositivo, tornando a ferramenta totalmente privada e segura.

Que nível de qualidade devo usar?

Para uso web, 60-70% é o ideal. Para impressão ou portefólios, experimente 80-90%. Para a compressão máxima (miniaturas, e-mail), 30-50% funciona bem.

Mais perguntas frequentes

Por que minha saída PNG está apenas um pouco menor que a original?

PNG é sem perda. A economia vem inteiramente de encontrar uma compressão DEFLATE mais apertada sobre os mesmos dados de pixel, o que tipicamente economiza 5 a 25 % em relação ao que uma ferramenta de autoria (Photoshop, Sketch, Figma) escreveu por padrão. Se seu PNG já estava bem otimizado, não sobra muita margem. Para conseguir redução adicional significativa, converta para WebP (que mantém transparência e costuma ser 25 % menor que PNG) ou aceite alguma perda convertendo para JPEG (que pode ser bem menor mas descarta transparência).

Esta ferramenta funciona offline?

Depois da primeira visita, sim. A biblioteca browser-image-compression (cerca de 95 KB minificada) fica em cache no navegador no primeiro carregamento. Visitas subsequentes ao compressor funcionam totalmente offline, desde que o cache do navegador não tenha sido limpo nesse meio tempo. Você pode verificar ativando o modo avião depois de abrir a página uma vez e comprimindo uma imagem local.

Meus dados EXIF (câmera, GPS, data de captura) serão preservados?

Não, os metadados EXIF são removidos durante a compressão por padrão. Para compartilhamento na web isso costuma ser desejável (coordenadas GPS e números de série de câmera não deveriam vazar), mas para fotógrafos arquivando com metadados intactos esta ferramenta não é a certa. Use um compressor de desktop ciente de EXIF como ImageOptim (macOS) ou jpegtran com a opção `-copy all` para preservar metadados.

Qual a diferença entre o redimensionamento de Largura Máxima e a redução de qualidade?

Redimensionar muda as dimensões em pixels da imagem: uma foto 4000x3000 redimensionada para 1920x1440 tem 75 % menos pixels a codificar, o que corta o tamanho do arquivo antes mesmo de qualquer compressão rodar. A redução de qualidade (o controle) controla com que agressividade o codificador JPEG ou WebP arredonda seus coeficientes DCT, o que torna os dados codificados menores por pixel. Os dois se somam: redimensione primeiro para diminuir a contagem global de pixels, depois reduza a qualidade do que sobrou. Para um fluxo «deixe isto pronto para a web» típico, defina Largura Máxima 1920, qualidade 70, e a saída fica em torno de 10-15 % do tamanho original.

Posso comprimir imagens HEIC do meu iPhone?

O suporte de navegador a decodificar HEIC é limitado (Safari em dispositivos Apple faz; Chrome e Firefox não). Em navegadores não-Apple esta ferramenta vai recusar arquivos HEIC. O fluxo para fotos de iPhone é ou mudar o ajuste do iPhone (Câmera → Formatos → Mais Compatível) para salvar JPEG direto, ou converter HEIC para JPEG uma vez num Mac ou com uma ferramenta dedicada, e então passar esses JPEGs por este compressor. A planilha «Compartilhar via» do iCloud costuma converter automaticamente para JPEG ao compartilhar com destinatários não-Apple.

Existe um equivalente de desktop ou de linha de comando?

Vários. Para automação em lote, sharp em Node.js é a biblioteca canônica do lado servidor e produz saída quase idêntica. ImageMagick (magick input.jpg -quality 70 output.jpg) e GraphicsMagick lidam com arquivos enormes e rodam de qualquer shell. jpegoptim e optipng são recodificadores especializados em JPEG e PNG que frequentemente arrancam mais alguns por cento em relação a ferramentas genéricas. Para trabalho interativo pontual como esta ferramenta mas com mais controles, Squoosh (Google Chrome Labs, também inteiramente do lado cliente) suporta uma faixa mais ampla de formatos, inclusive AVIF.

Ferramentas relacionadas