O arquivo que a IA devolve não é JPEG: por que o campo de foto recusa antes de olhar a imagem

Os doze primeiros bytes: descubra em que formato o seu arquivo está

Quando o campo de foto recusa o seu arquivo, a primeira pergunta não é qual é a extensão dele. É o que está escrito no começo dele. Todo contêiner de imagem abre com uma assinatura fixa de poucos bytes, e é isso que um servidor lê antes de decidir qualquer coisa. Doze bytes bastam para separar os cinco contêineres que aparecem nesta história, e nenhum deles está no nome do arquivo.

Rode uma destas linhas no arquivo que foi recusado.

# macOS ou Linux, no Terminal
file foto.webp
xxd -l 12 foto.webp

# Windows, no PowerShell 7
Get-Content foto.webp -AsByteStream -TotalCount 12 | Format-Hex

# Windows PowerShell 5.1, o que já vem instalado
Get-Content foto.webp -Encoding Byte -TotalCount 12 | Format-Hex

Linha a linha, em português: file responde em uma frase o que o arquivo é de verdade, olhando o conteúdo e ignorando o nome; xxd -l 12 imprime os doze primeiros bytes em hexadecimal e, ao lado, a versão legível deles; as duas linhas do PowerShell fazem a mesma leitura no Windows, e você escolhe conforme a versão instalada. Se em vez disso você abrir Propriedades no Explorador de Arquivos, ele vai repetir o que a extensão diz, que é justamente a informação sob suspeita.

Agora compare o resultado com esta lista. Medi as assinaturas byte a byte em 02/09/2026, no mesmo retrato salvo em cada contêiner:

• PNG: abre em 89 50 4E 47 0D 0A 1A 0A, e a parte legível mostra .PNG.
• JPEG: abre em FF D8 FF E0 e traz JFIF nos bytes 6 a 9.
• WebP: traz RIFF nos bytes 0 a 3 e WEBP nos bytes 8 a 11. É o caso mais comum quando a imagem saiu de um gerador.
• GIF: 47 49 46 38 39 61, que se lê como GIF89a (arquivos mais antigos abrem em GIF87a, com 37 no lugar do 39).
• HEIC: ftypheic nos bytes 4 a 11. É o padrão de gravação da câmera do iPhone.

Vale a advertência de quem já tropeçou nisso. Rodando file no acervo do meu próprio repositório, encontrei dez arquivos com extensão .webp cujo conteúdo é PNG: os primeiros bytes são 89 50 4E 47. Eles estavam ali havia meses, usados como material de outras medições, e ninguém tinha conferido. Descrever um arquivo pela extensão é o erro mais barato de cometer, inclusive dentro de casa.

Em que formato a imagem sai de cada caminho, e por que a resposta não é JPEG

O formato não é uma escolha que você faz na conversa. É um parâmetro da ferramenta que gera. O guia de geração de imagem da OpenAI é literal: "The Image API returns base64-encoded image data. The default format is png, but you can also request jpeg or webp" (a API de imagens devolve dados codificados em base64; o formato padrão é png, e também dá para pedir jpeg ou webp). Na referência da edição de imagem, a mesma casa escreve que "GPT image models always return base64-encoded images" (os modelos GPT de imagem sempre devolvem imagens em base64).

Repare no que isso implica. No meio do caminho não existe arquivo nenhum: existe um bloco de texto codificado. O arquivo passa a existir quando alguém decodifica esse bloco e grava em disco, e quem grava é que escolhe o contêiner e a extensão. Por isso pedir "me devolva em JPEG" dentro da conversa não seleciona nada. O texto do pedido governa o conteúdo da imagem, nunca o invólucro dela. Quem seleciona é um par de campos:

{
  "model": "gpt-image-2",
  "output_format": "webp",
  "output_compression": 80
}

Em português: output_format escolhe o contêiner do arquivo e output_compression regula a compressão numa escala de 0 a 100, com padrão 100. A referência avisa que a compressão "is only supported for the GPT image models with the webp or jpeg output formats" (só vale para os formatos de saída webp ou jpeg), ou seja, o PNG não tem essa alavanca. E o guia ainda recomenda o JPEG por velocidade: "Using jpeg is faster than png, so you should prioritize this format if latency is a concern".

No fotoslinkedin esse parâmetro está fixo em WebP. O gerador grava a imagem pronta com a extensão .webp e com o tipo image/webp declarado, nas três saídas do produto: 1024x1024, 1024x1536 e 1536x1024. É decisão de código, não acidente, e é exatamente a metade do contrato que este artigo trata.

O outro fornecedor descreve a mesma coisa com outro vocabulário. A documentação de geração de imagem do Gemini publica o formato como tipo MIME, e os exemplos oficiais usam image/jpeg e image/png. Nas 17.142 palavras que li dessa página em 02/09/2026, a palavra webp não aparece nenhuma vez, o que é uma ausência medida naquele dia e não uma declaração de incompatibilidade. A mesma página diz que "All generated images include a SynthID watermark", isto é, toda imagem gerada sai com uma marca d'água SynthID: um lembrete de que o arquivo carrega mais coisa do que pixel, e esse é o assunto de proveniência, que tem artigo próprio.

A superfície de conversa é o pior lugar para descobrir isso, porque ela não mostra o parâmetro em lugar nenhum: o botão de salvar entrega o arquivo já gravado, com o contêiner que a ferramenta escolheu antes de você chegar. No fórum de desenvolvedores do próprio fornecedor há relatos de usuários descrevendo exatamente esse susto, em tópicos com títulos como "DALL-E images downloading as WebP". É relato de usuário e não especificação, e precisa ser lido assim: o que a documentação publica é o parâmetro; o que a conversa entrega é o resultado dele.

Aqui está o ponto cego da anatomia do pedido. O blog descreve um prompt de foto em componentes, e o último deles é a saída, com proporção e uso final: a anatomia do pedido, componente por componente, está inteira no pilar. Dentro desse componente existe um sub-item que nenhuma frase alcança, porque ele não vive no texto: o contêiner. É irmão daquela outra restrição de saída, a que decide quantas imagens voltam de uma vez, e as duas se resolvem no mesmo lugar: no parâmetro, e não no adjetivo.

O campo recusa antes de olhar a imagem: o portão tem duas camadas

A recusa que você vê tem duas origens possíveis, e elas acontecem em momentos diferentes. A primeira camada é o seletor de arquivo, dentro do navegador. A segunda é o servidor do destino. Só a segunda decide de verdade.

A documentação da MDN sobre o campo de upload é direta sobre a primeira: "The accept attribute doesn't validate the types of the selected files; it provides hints for browsers to guide users towards selecting the correct file types" (o atributo accept não valida o tipo dos arquivos selecionados; ele dá dicas ao navegador para orientar a escolha). E completa: "you should make sure that the accept attribute is backed up by appropriate server-side validation" (é preciso garantir que o accept esteja respaldado por validação no servidor). Esse filtro trabalha com uma lista de extensões ou de tipos declarados, e é por isso que ele cai fácil.

A segunda camada trabalha com outra informação. A página da MDN sobre tipos MIME diz que "Browsers use the MIME type, not the file extension, to determine how to process a URL" (os navegadores usam o tipo MIME, e não a extensão, para decidir como processar um endereço). Do lado do servidor a lógica é a mesma, com um detalhe a mais: quem quer certeza abre o arquivo e lê a assinatura dele.

Testei o conselho mais repetido dos fóruns em português, que é renomear. Copiei um mesmo WebP de 48.272 bytes para três nomes, foto.webp, foto.jpg e foto.png, sem tocar em um único byte do conteúdo, e perguntei a cinco leitores o que eles viam:

• file: WebP nos três nomes.
• file --mime-type: image/webp nos três.
• sips -g format, que é do macOS: webp nos três.
• A biblioteca Pillow, no Python: WEBP nos três.
• A função que decide pelo nome, mimetypes.guess_type: image/webp, image/jpeg e image/png, um resultado diferente para cada nome.

É a última linha que explica a experiência de todo mundo. O que lê o nome muda de opinião. O que lê os bytes não muda. Renomear às vezes parece funcionar porque o arquivo atravessa o primeiro portão e morre no segundo, às vezes com uma mensagem genérica, às vezes depois de a barra de progresso ter chegado ao fim. Nenhum byte foi convertido no caminho: só a etiqueta.

Repare que nada disso tem a ver com qualidade. Um WebP impecável é recusado exatamente como um WebP ruim, porque a lista é de contêiner e não de nitidez. A perda que acontece dentro do arquivo, quando ele é reprocessado no caminho, é outro assunto e tem casa própria: quando a perda acontece dentro do arquivo, e não na portaria.

A mesma plataforma publica mais de uma lista, e uma delas depende do celular

Aqui está o erro estrutural deste assunto, e ele é fácil de cometer: procurar "o que a plataforma aceita", abrir a primeira página que aparece e sair escrevendo. A lista de formatos não pertence à plataforma. Pertence ao campo.

O Linkedin publica pelo menos três listas diferentes. A resposta sobre a foto que não carrega no perfil diz que "O tipo de arquivo precisa ser PNG ou JPG" e acrescenta que os GIFs não são aceitos. A página sobre amostras de mídia no perfil lista ".jpg/.jpeg, .png, .gif" ao lado de PDF, PowerPoint e Word. E a página sobre imagens compartilhadas em publicação traz uma tabela de três colunas, Computador, iOS e Android, em que GIF, JPEG e PNG passam nas três, o WEBP aparece marcado só no Android e o HEIF/HEIC só no iOS.

Leia a última de novo: naquele campo, a aceitação de formato depende do sistema operacional do aparelho de onde você posta. É por isso que a frase que a busca em português repete, a de que a plataforma não aceita WebP, está errada do jeito que está escrita. Quem não aceita WebP é o campo de foto do perfil. O campo de mídia da publicação aceita, em um dos três caminhos.

O padrão se repete nas outras casas. Na OLX, a página do perfil profissional publica "Formatos permitidos: JPG, GIF ou PNG", enquanto a página de como publicar um anúncio escreve "Adicione as fotos de até 5MB nos formatos JPG, GIF, PNG, HEIC ou WEBP". Mesma empresa, dois campos, duas listas: o anúncio aceita o contêiner que o seu rosto não pode usar. No Google acontece igual. O campo de foto dentro do perfil de empresa publica "Formato: JPG ou PNG", e o Merchant Center, que é catálogo de produto e não foto de pessoa, aceita "JPEG (.jpg/.jpeg), WebP (.webp), PNG (.png), GIF (.gif), BMP (.bmp), TIFF (.tif/.tiff)".

A consequência prática é uma regra de conferência simples: antes de converter qualquer coisa, ache a página do campo exato onde a foto vai morar, e não a página genérica da plataforma. A mesma disciplina vale para o mesmo problema nos formulários de vaga, em que cada sistema publica a própria régua de arquivo.

O piso de peso: o erro que aparece quando você segue o conselho da internet

O reflexo diante de um campo de upload é sempre o mesmo: comprimir para não estourar o limite. 8 MB aqui, 5 MB ali. Para o campo de foto do perfil, essa conta específica já está feita no artigo que trata do teto de peso e da conferência daquele campo, e não vou repeti-la aqui. Só que a faixa tem dois lados, e o de baixo já apareceu no blog uma vez: no campo de foto de vendedor, o peso mínimo é a régua que mais reprova arquivo, medido na dimensão mínima que a própria plataforma publica. O que este artigo acrescenta, é o cruzamento entre esse piso e a decisão de formato.

Duas das páginas que li publicam piso. O perfil profissional da OLX escreve "Tamanho do arquivo: Mín.: 240kb Máx.: 5MB". A ajuda do Perfil da Empresa no Google escreve "Formato: JPG ou PNG. Tamanho: entre 10 KB e 5 MB". Um mínimo publicado é uma regra que o conselho universal do nicho, o "converta para JPG", consegue violar sozinho.

Medi. Peguei 8 retratos de 1024x1024 gerados pelo próprio produto, todos personas sintéticas e nenhuma pessoa real, e salvei cada um em vários contêineres. As medianas ficaram assim: 51,4 KB no WebP como o produto entrega, 117,2 KB em JPEG na qualidade 95, 219,2 KB em JPEG na qualidade máxima e 393,8 KB em PNG. Repeti o teste num segundo conjunto, de 10 retratos com fundo mais detalhado: o JPEG na qualidade 95 deu mediana de 162,5 KB, com máximo de 188,8 KB, e o PNG deu 999,1 KB.

Agora cruze com o piso de 240kb. Na qualidade 95, que é a exportação alta que quase todo editor oferece, nenhum dos 18 retratos passou: o mais pesado parou em 188,8 KB. Só na qualidade máxima o JPEG encosta na régua, e mesmo assim o resultado se divide: 2 dos 8 retratos do primeiro conjunto passaram, com 248,6 KB e 255,4 KB, e no segundo conjunto, mais detalhado, passaram os 10. O PNG passou em 18 de 18. Ou seja: no campo que tem piso, o conselho universal produz um arquivo recusado por ser leve demais, e o formato que a internet trata como exagero é o que passa sempre. Do lado do teto, nenhuma das versões chega perto de incomodar.

Os limites desse número, porque eles importam mais que o número. KB aqui é medição datada com o meu material, não especificação de ninguém. A dimensão está fixa em 1024x1024 e aquele campo aceita até 2160x3840, então um arquivo maior pesa mais e passa: na medição feita para o campo de vendedor, com recorte horizontal de 1.378 x 1.024 px em qualidade 95, o JPEG ficou acima do piso. Retrato com fundo detalhado também pesa mais que retrato com fundo liso. A página escreve 240kb, e eu li como kilobytes. E a OLX não recusa JPEG: ela publica JPG na lista dela. O que a medição mostra é que os meus arquivos ficaram abaixo do piso, não que o formato seja proibido ali.

Converter custa qualidade? Medi, e a resposta incomoda os dois lados

A crença de mercado diz duas coisas ao mesmo tempo: que converter destrói a foto e que existe uma ordem sagrada para fazer isso, primeiro reduzir e só depois converter, sob pena de pagar duas recodificações. Testei a segunda parte, que não encontrei medida em nenhuma das páginas que li.

O método foi este. Parti de 8 retratos, montei uma referência decodificando o original e reduzindo para 400x400 sem recodificar nada, e comparei dois caminhos. O caminho A reduz primeiro e salva JPEG uma vez só. O caminho B salva JPEG a 1024, reabre, reduz e salva JPEG de novo, pagando duas recodificações. A métrica é o erro médio quadrático de cada caminho contra a referência, na imagem inteira.

O resultado: na qualidade 90, a ordem errada custou 2,2% a mais de erro na imagem. Na qualidade 80, 1,8%. Na 70, 2,4%. E num caso com o recorte fora da grade de compressão, deslocado em 37 e 53 pixels, que era onde eu esperava o pior, deu 1,8%. É quase nada. A ordem da conversão praticamente não importa para a qualidade, e quem escreve que converter depois "paga o dobro" está descrevendo um custo que não aparece na medição.

Sobram três regras, e elas são mais úteis que a ordem. A primeira: converta uma vez só, e não duas, porque a primeira recompressão já cobra quase toda a conta. A segunda: a decisão que realmente cobra caro é a dimensão final, e não o formato. Esse é outro assunto, e está medido em o que a redução de tamanho tira de um retrato.

A terceira é a única irreversibilidade da história, e ela não é de qualidade, é de conteúdo: o canal alfa. A MDN escreve, no guia de formatos de imagem, que "JPEG does not support an alpha channel" (o JPEG não suporta canal alfa). Passar por JPEG apaga a transparência, e nenhuma conversão posterior traz de volta, porque o dado deixou de existir. Se o seu arquivo precisa continuar com fundo vazio, o assunto inteiro está em o que se perde quando o fundo precisa continuar vazio.

O protocolo do arquivo final, em quatro passos

Quatro passos, nesta ordem, para qualquer destino. Eles levam menos tempo do que descobrir na tentativa e erro por que o formulário reclama.

1. Abra a página do campo, não a da plataforma. Procure três coisas nela: a lista de formatos, a faixa de peso (com a palavra mínimo, e não só máximo) e a faixa de dimensão. Anote a data da página quando ela for antiga: a ajuda do CNPq sobre a foto do currículo Lattes pede uma foto "em formato JPG de até 70k" numa página modificada pela última vez em 2008, e isso muda a confiança que você deposita na regra.
2. Recorte e redimensione primeiro. O recorte é uma decisão do destino, não do seu arquivo, e ele muda de destino para destino: a régua está em por que o mesmo rosto vira recortes diferentes em cada campo. Fazer isso antes de converter evita salvar o arquivo duas vezes.
3. Converta uma vez só, para um formato da lista daquele campo. Renomear nunca converte: quem converte é o programa que abre, decodifica e grava de novo. Pré-visualização no macOS (Arquivo, Exportar), Paint ou Fotos no Windows (Salvar como) e qualquer editor de celular servem. Se o campo tiver piso de peso, confira o tamanho depois de salvar e suba a qualidade, ou escolha PNG, até passar. Se a imagem precisa de fundo transparente, não passe por JPEG.
4. Confira os doze primeiros bytes, não o nome. file arquivo no macOS e no Linux, Format-Hex no PowerShell. Se a assinatura não bater com a extensão, você tem um arquivo renomeado nas mãos, e ele vai atravessar o seletor para ser recusado pelo servidor depois.

Antes de apertar enviar, uma conferência final que não é passo, é hábito: um arquivo só, com nome sem acento e sem espaço, no formato que aquele campo publica, dentro da faixa de peso dos dois lados e dentro da faixa de dimensão. Se o campo tiver piso de dimensão, como os 400 x 400 do campo de foto do perfil ou os 250 x 250 do Perfil da Empresa, redimensionar para baixo demais recria o mesmo problema na outra ponta.

O outro lado da parede: a foto do iPhone que não entra nem como referência

Até aqui o problema foi a saída. Ele existe igual na entrada, e a busca em português quase não trata disso: o arquivo que você usa como referência para gerar também precisa estar num contêiner que o outro lado leia.

A câmera do iPhone grava em HEIC por padrão. Na referência da edição de imagem da OpenAI, a lista publicada de entrada é literal: "each image should be a png, webp, or jpg file less than 50MB. You can provide up to 16 images" (cada imagem deve ser um arquivo png, webp ou jpg com menos de 50 MB, e dá para enviar até 16). HEIC e HEIF não estão nessa lista, o que é diferente de dizer que eles são bloqueados: é uma ausência na lista publicada, e é assim que ela deve ser lida.

O outro fornecedor faz o contrário. A documentação de entendimento de imagem do Gemini lista os tipos aceitos e inclui image/heic e image/heif ao lado de PNG, JPEG e WebP. Dois fornecedores, duas listas, o mesmo arquivo na sua mão. Mais uma vez, a lista pertence ao campo.

No fotoslinkedin isso é resolvido antes de o arquivo sair daqui. A rota de geração aceita jpeg, png, webp, heic e heif, com até 10 MB por arquivo e até 5 fotos por geração, e converte HEIC e HEIF para JPEG no servidor antes de mandar ao modelo. Tem um detalhe de implementação que vale para qualquer formulário: quando o navegador não declara o tipo do arquivo, o que acontece com HEIC mais do que gostaríamos, a verificação cai no nome e procura .heic ou .heif. É a única situação em que a extensão é a única informação disponível, e ela existe justamente porque o contêiner é novo demais para alguns navegadores.

Quando o leitor do outro lado não tem decodificador para HEIC, o sintoma é aquele "erro desconhecido" que a busca descreve. Reproduzi: converti um retrato para HEIC e a biblioteca de imagem do Python, sem o plugin de HEIF instalado, respondeu que não consegue identificar o arquivo, enquanto a função que decide pelo nome respondia image/heic sem hesitar. O nome era reconhecido, o conteúdo não. É uma demonstração do mecanismo com uma biblioteca, não a especificação de nenhuma plataforma.

O caminho publicado para parar de produzir o problema está na ajuda da Apple sobre HEIF e HEVC: "Abra Ajustes e toque em Câmera. Toque em Formatos e, em seguida, toque em Mais Compatível", e a partir daí as fotos novas passam a sair em JPEG. Para voltar ao arquivo menor, a mesma página manda escolher Alta Eficiência. Duas ressalvas: isso não converte nada do que já está na galeria, vale das próximas fotos em diante, e o ajuste é da câmera, então continua sendo você quem decide o formato de cada envio.

Resumo e próximos passos

Cinco frases resumem o artigo. O formato do arquivo é um parâmetro da ferramenta, não uma linha do seu pedido. A recusa é de lista, não de qualidade: um arquivo impecável no contêiner errado cai igual a um arquivo ruim. A mesma plataforma publica listas diferentes por campo, e uma delas depende do sistema operacional do aparelho. O teto de peso quase nunca é o problema, e o piso é, quando existe. E a extensão é rótulo: os doze primeiros bytes é que são o arquivo.

O que fazer agora, em ordem: abra a página do campo exato onde a foto vai morar, recorte na dimensão que ele publica, converta uma vez só para um formato da lista dele e confira a assinatura do arquivo antes de enviar. Se o campo tiver mínimo de peso, confira o tamanho depois de salvar, e não antes.

Para revisar como o pedido é montado antes de o arquivo existir, o ponto de partida é o pilar que abre o prompt de foto em componentes. Para a régua específica do campo de foto do perfil, com peso e dimensão daquele destino, vale a conferência dedicada ao campo do Linkedin. E se a sua saída veio com menos imagens do que você pediu, a restrição irmã desta, do lado da quantidade trata do outro limite que o texto do pedido não vence.