Conversor de imagens em lote gratuito

Converta várias imagens de uma vez entre PNG, JPG e WebP. Ajuste a qualidade, compare tamanhos de arquivo e baixe tudo instantaneamente.

Seus dados nunca saem do seu dispositivo
Solte as imagens aqui ou clique para navegar (JPEG, PNG, WebP, GIF, BMP, TIFF)

Processando…

Sobre a conversão de formato de imagem

Cada formato de imagem tem seu uso. O PNG é sem perdas, ideal para gráficos; o JPG é perfeito para fotos e oferece arquivos menores; o WebP é um formato moderno que combina qualidade e tamanho.

JPEG (1992), o formato fotográfico

O Joint Photographic Experts Group foi formado em Novembro de 1986 em Parsippany, Nova Jérsia, com membros provenientes da ISO TC97 SC2/WG8 e do grupo CCITT SGVIII. Seis anos de trabalho de comissão depois, o texto da Recomendação T.81 do CCITT foi aprovado a 18 de Setembro de 1992, com o texto idêntico publicado como Norma Internacional ISO/IEC 10918-1 em 1994. Essa publicação dupla é o momento em que o JPEG se tornou o formato fotográfico do mundo. O núcleo matemático é a transformada discreta do cosseno aplicada a blocos de 8×8 píxeis: cada bloco é decomposto numa soma de ondas cosseno; os componentes de alta frequência aos quais a visão humana é menos sensível são quantizados mais agressivamente do que os de baixa frequência que o olho nota primeiro. O cursor de «qualidade» visível ao utilizador é exactamente isso, um multiplicador na tabela de quantização. Maior qualidade significa divisores menores, mais precisão, ficheiros maiores. Menor qualidade significa mais zeros após a quantização, melhor codificação entrópica e um ficheiro menor à custa de blocos e artefactos de ringing visíveis. JPEG é com perdas por design: não existe configuração de qualidade na qual um round-trip JPEG seja matematicamente idêntico à sua entrada. Para fotografias de cenas naturais (rostos, paisagens, comida, qualquer coisa com gradientes suaves e tom contínuo) isto é irrelevante; a perda vive abaixo do limiar de sensibilidade da visão humana e o ficheiro é uma fracção do tamanho que um formato sem perdas produziria. Para gráficos com bordas duras, texto, line art ou grandes áreas de cor lisa, JPEG é a escolha errada: a mesma DCT borra as bordas nítidas com artefactos de ringing («ruído de mosquito») e fronteiras em blocos entre células 8×8.

PNG (Outubro 1996 / Janeiro 1997), o formato gráfico sem perdas

PNG (Portable Network Graphics) was developed in 1994 by an informal group outside W3C as a deliberate response to two problems with the existing options: GIF's patent encumbrance (covered below) and TIFF's complexity. The specification was approved as a W3C Recommendation on 1 October 1996, and on 15 January 1997 it was released by the IETF as RFC 2083. A second edition incorporating errata became a W3C Recommendation on 10 November 2003; a third edition adding APNG, HDR support and Exif handling was published on 24 June 2025. PNG is lossless, every encoded byte is recoverable. Internally, a PNG file is a sequence of typed chunks (IHDR header, IDAT compressed data, IEND end-of-file marker, plus optional ancillary chunks for colour profile, transparency, gamma and metadata). Pixel data is preprocessed by one of five row filters (None, Sub, Up, Average, Paeth) chosen per scanline to maximise compressibility, then run through DEFLATE, the same algorithm used in zip files and gzip. PNG supports four colour modes: greyscale, greyscale with alpha, indexed colour (palette of up to 256 entries, what people call PNG-8), and truecolor RGB (PNG-24) with optional 8-bit alpha (PNG-32). The alpha channel supports 256 levels of partial transparency per pixel, which is what makes it possible to anti-alias the edges of icons against any background without the dreaded "white halo" PNG-8 indexed transparency used to produce. PNG was designed as a web format and an archival format simultaneously, and that dual role is why it remains the default for screenshots, logos, line art, charts, and any image where pixel-perfect reproduction matters more than file size.

GIF (15 de Junho de 1987), o sobrevivente da animação e a saga das patentes

Steve Wilhite, líder de engenharia da CompuServe, introduziu o GIF a 15 de Junho de 1987 para resolver um problema específico: como partilhar imagens a cores através dos modems lentos do serviço online da CompuServe sem que os ficheiros engolissem a quota mensal do utilizador. A sua equipa escolheu o algoritmo de compressão Lempel-Ziv-Welch (LZW) e limitou a paleta de cores a 256 entradas. O que a CompuServe não sabia em 1987 era que o LZW tinha sido patenteado pela Sperry Corporation (mais tarde Unisys) em 1985. A questão das patentes irrompeu publicamente no final de 1994. A Unisys anunciou em 1995 que cobraria royalties sobre software que usasse o algoritmo (incluindo GIF, TIFF e PDF) a taxas de cerca de 0,45 % a 0,65 % das receitas. A comunidade open-source da web respondeu com duas acções paralelas: a campanha «Burn All GIFs» e o desenho do PNG, explicitamente para ser um substituto de GIF livre de patentes. A patente norte-americana da Unisys expirou em Junho de 2003; as patentes correspondentes noutras jurisdições expiraram até 2004. Em 2004, GIF estava livre de patentes pela primeira vez na sua história. O GIF sobreviveu por causa de uma funcionalidade que o PNG (originalmente) não tinha: animação. Suporta uma sequência de frames com tempos de atraso por frame e um índice de paleta transparente, o que o tornou a lingua franca das imagens-reacção em loop e dos banners web. A paleta de 256 cores é uma limitação real para fotos, e a transparência de 1 bit produz bordas feias ao sobrepor sobre um fundo colorido, mas para animações curtas em loop de conteúdo tipo cartoon, o GIF ainda ganha no suporte universal.

BMP (Maio 1990) e TIFF (Outono 1986), os redutos legados

O BMP (Bitmap, também chamado Windows Device Independent Bitmap) foi incorporado no Windows 3.0, lançado a 22 de Maio de 1990, onde se tornou o padrão para armazenamento de bitmap no ambiente gráfico Windows. É essencialmente sem compressão, o array de píxeis cru, opcionalmente alinhado a uma fronteira de 4 bytes por linha, com um pequeno cabeçalho à frente. Um BMP 1920×1080 24 bits é cerca de 6,2 MB; a mesma imagem como JPEG qualidade 85 pode ser 200 KB. O papel do BMP em 2026 é essencialmente como formato de intercâmbio legado e o formato que as capturas de ecrã do Windows usavam historicamente. O TIFF (Tagged Image File Format) foi publicado pela primeira vez pela Aldus Corporation no Outono de 1986 (Revisão 3.0); a Revisão 6.0 em Junho de 1992 acrescentou cor CMYK e YCbCr e JPEG-em-TIFF. A Adobe adquiriu a Aldus em 1994 e detém agora o copyright. O TIFF é único por ser um formato contentor em vez de um único esquema de codificação, um único ficheiro TIFF pode conter múltiplas imagens (TIFF multi-página, comum para fax e capítulos de livros digitalizados), usar qualquer um de vários métodos de compressão (nenhum, LZW, ZIP, JPEG, CCITT Grupo 3/4 para fax) e armazenar metadados essencialmente arbitrários através da sua estrutura de campos com etiquetas. Esta flexibilidade torna o TIFF o padrão para fluxos de pré-impressão, digitalização e arquivamento de documentos; essencialmente nunca é usado para imagens web. A sua presença na lista de entrada é para utilizadores que convertem fontes destinadas a impressão ou digitalizadas em formatos web-friendly.

WebP (30 de Setembro de 2010), o formato web moderno

A Google anunciou o WebP a 30 de Setembro de 2010 como um novo formato aberto para gráficos true-color comprimidos com perdas na web, produzindo ficheiros mais pequenos que JPEG a qualidade comparável. O formato é baseado na codificação de keyframe do codec de vídeo VP8, que a Google tinha adquirido com a compra da On2 Technologies. Inicialmente o WebP era apenas com perdas. A 18 de Novembro de 2011, a Google anunciou um modo de compressão sem perdas e suporte para transparência tanto em modo lossless como lossy; a libwebp 0.2.0 atingiu uma implementação lossless estável a 16 de Agosto de 2012. Segundo a documentação para programadores da Google: as imagens WebP lossless são aproximadamente 26 % mais pequenas do que as mesmas imagens em PNG, e as imagens WebP lossy são 25-34 % mais pequenas do que JPEG comparáveis a qualidade SSIM equivalente. Estas reduções não são mágicas, vêm de um design de codec fundamentalmente mais novo (codificação intra-frame preditiva, codificação entrópica aritmética moderna, transformações de cor mais inteligentes) do que as bases do início dos anos 1990 contra as quais o JPEG e o PNG foram desenhados. O suporte do navegador foi uma construção lenta: Chrome 17 em Fevereiro de 2012 (lossy), Chrome 23 em Novembro de 2012 (lossless). A Apple aguentou-se a maior parte de uma década e finalmente acrescentou suporte WebP no Safari 14, que foi lançado com iOS 14 e macOS 11 Big Sur em Setembro de 2020. Essa data de Setembro de 2020 é o momento em que o WebP se tornou praticamente utilizável como formato web principal sem um fallback JPEG para utilizadores de iPhone. A cobertura hoje é aproximadamente 97 % do tráfego global, o WebP já não é um formato «moderno» com ressalvas, é um padrão.

Para além do WebP: AVIF (Fev 2019), HEIC (2017), JPEG XL (2018-)

O AVIF v1.0.0 foi lançado a 19 de Fevereiro de 2019 pela Alliance for Open Media (AOMedia, um consórcio de Google, Netflix, Microsoft, Mozilla, Cisco, Intel, Amazon, Apple). É o perfil de imagem fixa do codec de vídeo AV1, construído sobre o contentor HEIF, e é actualmente o formato de imagem amplamente implantado que melhor comprime, a qualidade visual equivalente, os ficheiros AVIF são tipicamente 50 % mais pequenos do que JPEG e 20-30 % mais pequenos do que WebP. O suporte do navegador chegou em três vagas: Chrome 85 (Agosto de 2020), Firefox 93 (Outubro de 2021), Safari com iOS 16 (Setembro de 2022) e macOS Ventura (Outubro de 2022). HEIC é o formato padrão do iPhone desde iOS 11 em 2017, o contentor HEIF com imagens comprimidas com HEVC, formalmente ISO/IEC 23008-12. A compressão é excelente (tipicamente 50 % mais pequena que JPEG) mas o HEVC tem patentes, razão pela qual Chrome, Firefox e Edge não-Apple recusam descodificar HEIC nativamente. JPEG XL (ISO/IEC 18181, 2022) é o formato tecnicamente excelente mas de nicho, pode recomprimir sem perdas JPEGs existentes para cerca de 20 % mais pequenos, suporta HDR, gama larga, animação e descodificação progressiva, e é livre de patentes. O Chrome retirou a sua flag experimental a 31 de Outubro de 2022 (a «decisão Halloween»); a Apple lançou o Safari 17 em Setembro de 2023 com JPEG XL nativo em macOS Sonoma, iOS 17 e visionOS. O formato é suportado nativamente no Safari 17+, atrás de uma flag no Firefox e no Chrome 145 (Fevereiro de 2026), mas a entrega por defeito para tráfego geral permanece pendente. Este conversor actualmente não emite AVIF, HEIC nem JPEG XL, estão listados aqui para que possa decidir se os trata a montante.

Escolher o formato de saída certo

A história formato a formato acima é uma visita. A questão prática é mais curta: dada uma imagem particular e um uso particular, qual o formato de saída correcto?

O que o cursor de qualidade realmente faz

O cursor de qualidade vai de 10 a 100 em passos de 5. Por trás desse único número está uma relação surpreendentemente não linear entre qualidade percebida e tamanho de ficheiro. Para JPEG, o consenso na engenharia de processamento de imagem é que qualidade 75-85 é o sweet spot. A qualidade 80, o tamanho de ficheiro cai 70-90 % a partir de uma fonte sem compressão com diferença visual imperceptível a distâncias normais de visualização de ecrã. A queda entre qualidade 80 e 85 é abrupta: uma imagem de teste representativa pode ir de 3,7 MB a qualidade 80 para 6 MB a qualidade 85, quase uma duplicação sem melhoria visível num ecrã de telemóvel ou portátil. Qualidade 75 é onde os artefactos começam a tornar-se detectáveis em inspecção próxima de detalhes de alta frequência (bordas de texto, texturas finas). Qualidade 90 e acima é para JPEGs de arquivamento onde o tamanho do ficheiro é irrelevante. O padrão de 80 senta-se na extremidade baixa do sweet spot, apropriado para optimização web em lote, onde o objectivo é entregar o mínimo de dados possível mantendo imagens que pareçam aceitáveis. Para WebP, o padrão da API canvas toBlob('image/webp') é qualidade 0,80; WebP a qualidade 70 é geralmente tão visualmente limpo como JPEG a qualidade 80. Para PNG, «qualidade» é uma denominação errada, PNG é sempre sem perdas nos dados de pixel. O cursor nesta ferramenta não tem efeito quando PNG é seleccionado como formato de saída. A lição crucial para processamento em lote: uma única configuração de qualidade raramente é correcta para cada imagem num lote misto. Uma pasta de 50 fotos tiradas com a mesma câmara na mesma iluminação pode provavelmente toda guardar-se a qualidade JPEG 80 sem perda. Uma pasta misturando capturas de ecrã, fotos, line art e logos não pode, um «converter tudo para JPG-80» de um botão transformará as capturas de ecrã em ruído de mosquito ilegível. Divida a entrada em lotes separados quando o conteúdo varie.

Lossy vs lossless, a distinção mais importante

Um codificador sem perdas garante que a saída descodificada é bit-idêntica à entrada codificada. PNG é lossless. WebP-lossless é lossless. TIFF (nos seus modos lossless) é lossless. O trade-off é o tamanho do ficheiro: codificadores sem perdas não podem explorar diferenças perceptuais imperceptíveis e devem preservar tudo. Uma fotografia 1920×1080 como PNG lossless pode ser 5 MB; a mesma foto como JPEG-qualidade-85 é 200 KB. O PNG é bit-perfeito; o JPEG é visualmente equivalente. Um codificador lossy descarta informação que o sistema visual humano é menos provável de notar, detalhe de alta frequência, fina variação de croma em cores saturadas, o quarto algarismo significativo de cada gradiente. JPEG, WebP lossy e AVIF lossy fazem todos isto. As implicações para um conversor em lote são concretas: lossless para lossless (PNG para PNG, ou PNG para WebP-lossless) é genuinamente sem perdas através de qualquer número de conversões; lossy para lossy à mesma qualidade (JPEG-85 para JPEG-85) não é lossless, cada re-codificação aplica outro passo de quantização, repita 10 vezes e o resultado está visivelmente degradado; lossy para lossless (JPEG para PNG) congela os artefactos existentes no lugar mas não os re-degrada; lossless para lossy introduz compressão com perdas no momento da conversão e não há forma de recuperar o detalhe descartado mais tarde. Os utilizadores frequentemente voltam a executar uma conversão esperando que seja um no-op. Fora do caso lossless-para-lossless, não é.

EXIF, IPTC, XMP, e porque esta ferramenta os retira

Ficheiros JPEG e HEIC de câmaras e telemóveis transportam um bloco EXIF, metadados Exchangeable Image File Format incorporados no cabeçalho da imagem. EXIF inclui modelo de câmara, lente, configurações de exposição, data e hora, versão de software, e mais consequencialmente as coordenadas GPS de onde a foto foi tirada (se os serviços de localização estavam ligados no momento da captura). Os metadados IPTC adicionam legenda, byline, copyright e palavras-chave. XMP, originalmente da Adobe, é um superconjunto baseado em XML que subsume os formatos mais antigos e é o que Lightroom e Photoshop usam. As implicações de privacidade são significativas. Uma foto tirada num iPhone com localização activada incorpora coordenadas GPS precisas a poucos metros. Partilhá-la num fórum, num anexo de email, ou via um blog pessoal pode revelar o endereço de casa do fotógrafo, a escola do filho, o local de trabalho, a rota de caminhada. Plataformas sociais principais (Facebook, Instagram, Twitter/X) retiram EXIF no upload antes de servir a imagem a outros utilizadores, mas leem e armazenam os metadados originais elas próprias. Fóruns mais pequenos, blogs WordPress, Discord, clientes de email e transferências directas de ficheiros deixam EXIF intacto. A re-codificação através da API canvas (o motor que esta ferramenta usa) descarta por defeito todos os metadados EXIF, IPTC e XMP. A saída é uma imagem limpa sem proveniência incorporada, uma característica de privacidade, e um efeito secundário do pipeline canvas (o canvas só armazena dados de pixel; não tem noção de metadados a preservar). Utilizadores que querem preservar metadados (fotógrafos a arquivar dados de exposição, fluxos de conteúdo onde o copyright deve viajar com o ficheiro) precisam de uma ferramenta diferente, tipicamente o convert do ImageMagick ou uma biblioteca dedicada consciente de EXIF. Este conversor corta no sentido contrário: é metadata-stripping por design, o que é exactamente o que um utilizador consciente da privacidade quer quando envia imagens a um fórum onde não quer que as suas coordenadas GPS o sigam.

Fundos transparentes, a escolha PNG-para-JPEG

PNG suporta um canal alpha por pixel: cada pixel tem uma opacidade de 0 (totalmente transparente) a 255 (totalmente opaco). JPEG não tem canal alpha. Converter um PNG com transparência para JPEG força uma escolha: o que devem os pixels transparentes tornar-se? O padrão da API canvas é compor contra preto transparente, por isso o JPEG resultante resolve os pixels transparentes para preto opaco. Um logo num fundo transparente convertido PNG-para-JPEG sai com cantos pretos à volta do logo, praticamente nunca o que o utilizador queria. A mitigação é preencher o canvas com uma cor de fundo escolhida (branco é o padrão típico) antes de desenhar a imagem por cima. Utilizadores que precisem de preservar a transparência devem escolher PNG ou WebP como formato de saída. WebP suporta transparência em ambos os modos lossless e lossy, o que o torna a escolha moderna quando a fonte tem transparência e o destino precisa de ser eficiente, um PNG de fundo transparente de 50 KB pode tornar-se um WebP lossy de fundo transparente de 12 KB preservando o canal alpha.

Como a conversão corre no seu navegador

A afirmação de que «tudo corre no seu navegador» assenta em três APIs da Plataforma Web que só recentemente se tornaram poderosas o suficiente para fazer de um conversor de imagens em lote um produto cliente-side credível. APIs FileReader e Blob: quando deixa cair ficheiros na zona de upload, cada File é uma subclasse de Blob que expõe ou readAsDataURL() (callback mais antigo) ou file.arrayBuffer() (baseado em Promise). Para imagens especificamente, o caminho mais simples é construir um URL Blob com URL.createObjectURL(file) e atribuí-lo a um novo elemento Image, deixando o descodificador de imagem incorporado do navegador tratar JPEG, PNG, GIF, WebP e BMP nativamente. A API Canvas: uma vez carregada uma Image, a conversão é uma dança em dois passos, desenhar com ctx.drawImage(img, 0, 0), depois ler o canvas de volta com canvas.toBlob(callback, type, quality). O parâmetro type é uma string MIME ('image/png', 'image/jpeg', 'image/webp'); o parâmetro quality é um número entre 0 e 1 para formatos lossy. OffscreenCanvas e Web Workers: para lotes grandes, fazer todo o trabalho de canvas no thread principal bloqueia a UI. A solução moderna é OffscreenCanvas, que expõe operações de canvas num contexto worker e é ela própria transferível para um Web Worker via postMessage sem cópia. O worker executa o pipeline descodificar-rasterizar-codificar num thread separado, mantendo a página responsiva. Juntas, estas APIs fazem com que um lote de 50 ficheiros corra em segundos sem bloquear scrolling ou cliques de botões. JSZip (uma biblioteca pura-JavaScript com licença MIT) trata do empacotamento ZIP final totalmente em memória antes de a caixa de diálogo de gravação do navegador disparar. Sem upload, sem zip de servidor, sem ficheiro temporário em disco. Há uma década, um conversor de imagens em lote que corresse no navegador teria sido uma curiosidade. A performance de WebAssembly, o paralelismo OffscreenCanvas e a RAM moderna de telemóvel (6-12 GB) e contagens de núcleos (6-8 CPUs) inverteram esse quadro. O argumento de privacidade fecha o caso: conversores do lado do servidor exigem fazer upload das suas imagens para uma máquina de terceiros, e mesmo com uma política de eliminação escrupulosa, o próprio upload é um evento de rede que pode ser registado, interceptado ou comprometido. Um conversor apenas-no-navegador nunca envia um byte.

Perguntas frequentes

Quais formatos de imagem são suportados?

O conversor processa a maioria dos formatos comuns (JPG, PNG, GIF, WebP, BMP, TIFF) e converte para PNG, JPG ou WebP.

Posso ajustar a qualidade para JPG e WebP?

Sim. Use o controle de qualidade para ajustar a compressão (0-100). Valores mais altos resultam em melhor qualidade, mas arquivos maiores.

Como baixar vários arquivos?

Escolha "Baixar tudo em ZIP" para agrupar todas as imagens convertidas em um único arquivo ZIP, prático para baixar e salvar.

Porque é o limite 50 ficheiros por lote?

É um tecto de memória. Cada imagem tem de ser descodificada para RAM como dados de pixel crus antes de o canvas a poder re-codificar. Uma foto iPhone de 12 megapixels descodifica para cerca de 36 MB de dados de pixel (12 milhões de pixels × 3 bytes RGB, ou 4 bytes RGBA). 50 dessas de uma vez são 1,8 GB de memória de trabalho. A maioria dos portáteis trata disso confortavelmente; telemóveis mais antigos não. O tecto de 50 ficheiros mantém a página previsível em todos os dispositivos. Para lotes maiores, execute a ferramenta em rondas, digamos, 50 ficheiros, descarregar, limpar, deixar cair mais 50.

Há um limite de tamanho por ficheiro?

Sem tecto rígido, o limite é a memória disponível do seu dispositivo. Uma única imagem de 50 MP descodifica para cerca de 150 MB de dados de pixel, o que funciona num desktop mas terá dificuldades num telemóvel mais antigo. Como regra de bolso, ficheiros abaixo de 10 MB convertem suavemente em essencialmente qualquer dispositivo; ficheiros acima de 50 MB irão abrandar ou falhar em móvel de gama inferior. Se uma conversão congelar, recarregue a página e experimente o ficheiro num lote mais pequeno.

O conversor retira os metadados EXIF?

Sim, por design. O pipeline de re-codificação canvas só armazena dados de pixel, por isso blocos de metadados EXIF, IPTC e XMP (modelo de câmara, configurações de exposição, coordenadas GPS, etiquetas de copyright, histórico de edição) não sobrevivem ao round-trip. A saída é uma imagem limpa sem proveniência incorporada, o que é uma vitória de privacidade quando está a partilhar fotos a fóruns ou contactos de email onde não quer que coordenadas GPS o sigam. Se precisar de metadados preservados (fotógrafos a arquivar dados de exposição, fluxos de conteúdo que requerem etiquetas de copyright), esta é a ferramenta errada, use o convert do ImageMagick ou uma biblioteca dedicada consciente de EXIF que preserve metadados explicitamente.

O que acontece aos fundos transparentes quando converto PNG para JPG?

JPEG não tem canal alpha, por isso pixels transparentes no PNG fonte têm de tornar-se alguma cor opaca na saída JPEG. O comportamento padrão do canvas é compor contra um fundo colorido (tipicamente branco). Um logo num fundo PNG transparente convertido para JPEG perderá a transparência e captará o preenchimento de fundo. Se a transparência importa, escolha PNG ou WebP como formato de saída, ambos preservam alpha. WebP-lossy preserva transparência a tamanhos de ficheiro dramaticamente menores do que PNG e é a escolha moderna para gráficos web transparentes.

As minhas imagens são carregadas para algum lugar?

Não. Todos os passos (selecção de ficheiros, descodificação, re-codificação canvas, empacotamento ZIP, descarga) correm totalmente no seu navegador via JavaScript. Não há processamento do lado do servidor. Pode verificar abrindo o separador Network das DevTools do seu navegador enquanto converte: não há pedidos de saída transportando dados de imagem. A página é segura para capturas de ecrã sensíveis, digitalizações de documentos, fotos pessoais com metadados de localização, ou qualquer outra coisa que não queira ver copiada para o disco rígido de um estranho.

Ferramentas relacionadas

PDF → HTML

Converta PDF em HTML instantaneamente.

Codificador Base64

Codifique imagens em Base64.

Texto → CSV

Converta dados para o formato CSV.