Dados de GPS em fotos: o que o WordPress entrega em imagens pequenas e como removê-los

Câmeras e celulares gravam num arquivo de imagem mais do que a imagem: fabricante e modelo, hora da foto, exposição e, se a localização estiver ligada, o lugar da foto como latitude e longitude. Tudo isso fica no bloco EXIF, no começo do arquivo. Quem carrega a foto carrega o bloco junto.

O próprio WordPress não mostra essas informações em lugar nenhum. No banco de dados ele guarda câmera, abertura, tempo de exposição e hora da foto, e as coordenadas não estão entre os campos que ele lê. Isso tranquiliza cedo demais, porque as coordenadas estão no arquivo, e o arquivo vai para cada visitante.

A falha de que trata este artigo também existia no nosso próprio plugin de galerias. Até a versão 1.2.5, o Heckgalerie só limpava o arquivo em tamanho completo quando o próprio WordPress o tinha criado, por exemplo como -scaled em fotos grandes. Por isso, fotos pequenas saíam com GPS, por exemplo na lightbox, e em servidores com Imagick os tamanhos intermediários também. A versão 1.2.6 corrige as duas coisas. Para este artigo, medimos primeiro o que o WordPress entrega sem plugin nenhum.

Como medimos

WordPress 7.1.3 com PHP 8.3 no WordPress Playground, em 12 de outubro de 2026. A foto de teste é um JPEG gerado por nós com um bloco EXIF: fabricante da câmera, modelo, hora da foto e coordenadas de GPS em Hamburgo. Enviamos a foto pelo mesmo processamento no servidor usado nos envios para a biblioteca de mídia, em dois tamanhos: 1.600 × 1.200 pixels, abaixo do limite, e 4.000 × 3.000 pixels. Depois lemos cada arquivo da pasta de uploads duas vezes, com a função exif_read_data do PHP e com um leitor próprio que percorre o bloco EXIF byte por byte. Os dois deram o mesmo resultado em todos os arquivos.

Uma observação sobre o editor de imagens. O WordPress processa imagens com a extensão GD do PHP ou com o Imagick, e escolhe o Imagick quando os dois estão disponíveis. No Playground a escolha cai no GD, porque lá a extensão Imagick não informa número de versão e não passa na verificação do WordPress. Para a coluna do Imagick, forçamos então o editor Imagick do próprio WordPress e pulamos apenas essa verificação. O trabalho foi feito pelo ImageMagick 7.1.1.

O que o WordPress entrega

GPS significa que latitude e longitude continuavam no arquivo sem alteração. Limpo significa que não havia mais bloco EXIF.

A primeira linha é o centro deste artigo. Se o lado maior de uma foto não passa de 2.560 pixels, o WordPress não cria uma versão reduzida com o sufixo -scaled. O arquivo em tamanho completo é então a foto do jeito que foi enviada, seja qual for o editor. No código, o limite se chama big_image_size_threshold e vem definido como 2.560. Uma foto de 12 megapixels (4.032 × 3.024) fica acima dele, enquanto uma foto reduzida ou recortada antes do envio pode ficar abaixo. Se os metadados sobrevivem a essa redução depende do programa.

A segunda descoberta está na coluna do Imagick. O editor Imagick do WordPress até remove perfis ao reduzir, mas deixa cinco de fora de propósito: icc e icm para as cores, iptc para os direitos autorais, xmp para os direitos de uso e exif para a orientação. O GPS fica no bloco EXIF, então ele permanece em todos os tamanhos. O filtro image_strip_meta só liga ou desliga essa limpeza. Medimos as duas opções, e o resultado foi o mesmo. O GD descarta os perfis de qualquer forma: é o que diz o código-fonte do WordPress, e foi o que vimos na medição.

Com GD encontramos uma exceção: uma foto pequena que só fica em pé por causa de uma instrução de rotação no EXIF é girada pelo WordPress no envio e salva de novo como -rotated. Essa versão estava limpa. O original também fica aqui ao lado.

Onde o original aparece no seu site

Um original na pasta de uploads seria metade do problema se nada apontasse para ele. Com a foto pequena, o WordPress aponta para ele em vários lugares, sem que ninguém escolha de propósito o tamanho completo. Medimos o HTML que o WordPress gera para um bloco de imagem:

• srcset: Mesmo quando você insere a imagem menor, por exemplo com 1.024 pixels de largura, o WordPress coloca o original no srcset como versão de 1.600 pixels. Até 2.048 pixels de largura ele inclui ali o tamanho completo (filtro max_srcset_image_width). Qual arquivo o navegador baixa depende da largura da tela e da densidade de pixels. Como o WordPress define o srcset e os tamanhos de imagem, explicamos no artigo sobre lazy load no WordPress.
• Ampliar ao clicar: A lightbox do bloco de imagem carrega o arquivo em tamanho completo, ou seja, na foto pequena, o original.
• Link para o arquivo de mídia: Tanto num bloco de imagem quanto numa galeria, o link leva ao tamanho completo.
• Tamanho completo: Quem insere a imagem assim incorpora o original diretamente.

Na foto grande, o srcset só listava tamanhos intermediários de até 2.048 pixels, e a lightbox apontava para o arquivo -scaled. O WordPress não coloca link para o original de 4.000 pixels em lugar nenhum do HTML. Mas ele está na mesma pasta, e o endereço dele é o do arquivo -scaled sem esse sufixo. Quem conhece um conhece os dois. O nome do arquivo o próprio WordPress revela: a API REST pública em /wp-json/wp/v2/media o informa no campo original_image, na nossa medição também para visitantes sem login.

O que muda com o Heckgalerie 1.2.6

O Heckgalerie é o nosso plugin de galerias no diretório do WordPress. Ele tem o filtro de EXIF desde a versão 1.0.0. O filtro vale para todo JPEG que entra na biblioteca de mídia, não só para imagens de galeria, e vem ligado de fábrica. A versão 1.2.6 está no diretório desde 12 de outubro de 2026. Em que o Heckgalerie se diferencia de outros plugins de galeria, mostramos no comparativo de alternativas ao NextGEN Gallery.

Se uma foto fica abaixo do limite, o Heckgalerie agora coloca ao lado do original uma cópia limpa com o sufixo -web e faz dela o arquivo em tamanho completo, do mesmo jeito que o WordPress faz com o -scaled. A partir daí, o srcset, a lightbox do bloco de imagem, as galerias do Heckgalerie e as imagens inseridas de novo apontam para a cópia. O arquivo -scaled e todos os tamanhos intermediários são limpos no próprio lugar, também em servidores cujo editor carrega os metadados junto.

Repetimos a mesma medição com o pacote do diretório do Heckgalerie 1.2.6, com GD e com Imagick. Depois disso, nenhum arquivo entregue tinha GPS. O caminho pelo navegador, o do quadro sobre o editor de blocos, não medimos com o Heckgalerie. A cópia da foto pequena tinha 309 bytes a menos que o original: exatamente o bloco EXIF e um comentário que o GD tinha gravado ao criar a foto de teste. Os dados de imagem logo depois eram idênticos byte a byte. Ou seja, o Heckgalerie não recalcula nada, só deixa de fora as seções de metadados.

O que fica e o que sai está no código-fonte. Ficam o perfil de cor e a marca da Adobe, sem a qual imagens CMYK mostram cores erradas. Saem EXIF, XMP, IPTC e comentários, além das imagens de pré-visualização e secundárias que alguns celulares anexam atrás da foto e que podem ter dados de GPS próprios.

Há três limites:

• Só JPEG. PNG e WebP passam sem alteração.
• O original fica. O Heckgalerie não mexe no arquivo enviado. Ele continua na pasta de uploads, no caso da foto pequena com o nome sem -web. Em envios novos, o HTML da página não aponta mais para ele. A API REST continua informando o nome dele no campo original_image, e qualquer pessoa que conheça o endereço ainda consegue baixá-lo.
• Dá para desligar. O botão fica nas configurações do Heckgalerie. Se você quer manter os metadados nos arquivos entregues, desligue-o.

Fotos antigas: o que regenerar as miniaturas resolve

Fotos enviadas antes da versão 1.2.6 são limpas pelo Heckgalerie assim que as miniaturas delas são regeneradas, por exemplo com wp media regenerate. Reproduzimos isso com uma foto de 1.600 pixels que tinha sido inserida antes da ativação em cinco posts: uma vez em tamanho completo, uma vez com 1.024 pixels de largura e três vezes com 1.024 pixels e link para o arquivo de mídia, como bloco de imagem, num bloco Galeria e no editor clássico.

Depois de regenerar, a imagem inserida menor e sem link mostrava no srcset a cópia limpa sem que ninguém editasse o post, porque o WordPress calcula o srcset só na hora de exibir. A imagem em tamanho completo e os três links continuavam apontando para o original com GPS, porque o endereço deles fica fixo no post. O changelog diz isso para imagens em tamanho completo, mas não menciona os links. A solução: inserir a imagem ou a galeria mais uma vez, ou refazer o link. A partir daí, o endereço do arquivo de mídia é o da cópia, e no nosso teste as imagens inseridas de novo apontavam para ela.

Esses posts você encontra com a busca da lista de posts ou de páginas, que também procura no conteúdo. Digite o nome de arquivo do original, por exemplo foto.jpg. No nosso teste, assim ela encontrou a imagem em tamanho completo e os três links, e deixou de fora a imagem menor sem link. A busca por size-full, a classe que o WordPress coloca nas imagens em tamanho completo tanto no editor de blocos quanto no clássico, encontra essas imagens de todas as fotos de uma vez, mas não os links. As duas buscas só cobrem posts e páginas: imagens em widgets ou em modelos do editor do site não aparecem assim.

Sem o Heckgalerie: verificar e agir

Qual editor está ativo?

Em Ferramentas → Diagnóstico, aba Informação, o campo Editor ativo da seção Manipulação de mídia mostra qual editor de imagens está em uso: WP_Image_Editor_Imagick ou WP_Image_Editor_GD. Com Imagick vale a coluna da direita da tabela, com a ressalva do quadro sobre o editor de blocos.

Verificar um arquivo

Abra uma foto do seu site em tamanho completo, pela lightbox ou pelo link para o arquivo de mídia, e salve. No Windows, clique com o botão direito no arquivo, escolha Propriedades e a aba Detalhes para ver se existe uma seção GPS com latitude e longitude. O sistema de propriedades do Windows, de onde essa aba lê os dados, devolveu as coordenadas da nossa foto de teste e nada para os tamanhos intermediários do teste com GD. Mas, se houver uma CDN ou um otimizador de imagens na frente do seu site, assim você verifica o que ele entrega, não o arquivo no servidor. Para os arquivos no servidor, use a linha da próxima seção.

Encontrar todos os arquivos de uma vez

Com o WP-CLI, uma única linha lista todos os JPEG da pasta de uploads que têm coordenadas. Ela precisa da extensão exif do PHP:

wp eval 'foreach ( new RecursiveIteratorIterator( new RecursiveDirectoryIterator( wp_get_upload_dir()["basedir"] ) ) as $f ) { $x = preg_match( "/\.jpe?g$/i", $f ) ? @exif_read_data( (string) $f, "GPS" ) : false; if ( ! empty( $x["GPSLatitude"] ) ) { echo $f, PHP_EOL; } }'

No nosso teste com 26 arquivos, ela listou exatamente os oito com GPS: o original de uma foto pequena, o original de uma grande atrás do -scaled e uma foto enviada com Imagick junto com seus cinco tamanhos intermediários.

Agir

Limpar antes de enviar. Só assim as coordenadas nunca chegam ao servidor. No Windows: botão direito, Propriedades, aba Detalhes e, embaixo, o link para remover propriedades e informações pessoais, com a opção de criar uma cópia sem todas as propriedades possíveis. Depois verifique a cópia como descrito acima. No celular, dá para configurar a câmera para não salvar a localização.

Em servidores com Imagick, dar preferência ao GD. Um filtro num pequeno plugin próprio ou no functions.php de um tema filho coloca o GD na frente, e o Imagick continua disponível para formatos que o GD não suporta:

add_filter( 'wp_image_editors', function () {
	return array( 'WP_Image_Editor_GD', 'WP_Image_Editor_Imagick' );
} );

Os tamanhos existentes só ficam limpos quando você regenera as miniaturas, foi assim que medimos. Nos originais e nas fotos pequenas em tamanho completo a troca não muda nada. Também não ajuda com fotos no formato HEIC, como alguns celulares salvam: o GD não lê HEIC, então, segundo o código-fonte, o WordPress continua processando essas fotos com o Imagick. E o GD também descarta perfis de cor: fotos num espaço de cor diferente do sRGB podem parecer um pouco diferentes nos tamanhos intermediários.

Limpar os arquivos existentes. O que a linha do WP-CLI acima encontrar pode ser limpo direto no servidor com uma ferramenta como o ExifTool, depois de um backup. Remova só os dados de GPS, por exemplo com exiftool -gps:all= -overwrite_original. Sem -overwrite_original, o ExifTool deixa ao lado de cada arquivo uma cópia terminada em _original, e essa cópia continua com as coordenadas. Não apague os originais nem o restante dos dados deles: segundo o código-fonte, o WordPress calcula os tamanhos novos a partir do original e os endireita pela instrução de rotação do EXIF.

Perguntas frequentes