GPS-gegevens in foto's: wat WordPress bij kleine afbeeldingen uitlevert, en hoe je ze verwijdert

Camera's en telefoons schrijven meer in een afbeeldingsbestand dan de afbeelding: merk en model, opnametijd, belichting en, als locatie aanstaat, de plek van de opname als breedte- en lengtegraad. Dat staat allemaal in het EXIF-blok aan het begin van het bestand. Wie de foto laadt, laadt het blok mee.

WordPress zelf toont deze gegevens nergens. In de database bewaart het camera, diafragma, sluitertijd en opnametijd, en coördinaten horen niet bij de velden die het uitleest. Dat stelt te vroeg gerust, want de coördinaten staan in het bestand, en het bestand gaat naar elke bezoeker.

Het lek waar dit artikel over gaat, zat ook in onze eigen galerijplugin. Tot en met versie 1.2.5 schoonde Heckgalerie het bestand op volledige grootte alleen op als WordPress het zelf had aangemaakt, bijvoorbeeld als -scaled bij grote foto's. Kleine foto's gingen daardoor met GPS naar buiten, bijvoorbeeld in de lightbox, en op servers met Imagick ook de tussenformaten. Versie 1.2.6 dicht beide. Voor dit artikel hebben we eerst gemeten wat WordPress zonder plugin uitlevert.

Zo hebben we gemeten

WordPress 7.1.3 met PHP 8.3 in WordPress Playground, op 12 oktober 2026. De testfoto is een zelf gemaakte JPEG met een EXIF-blok: cameramerk, model, opnametijd en GPS-coördinaten in Hamburg. We hebben hem geüpload via dezelfde verwerking op de server als bij uploads naar de mediabibliotheek, in twee formaten: 1.600 × 1.200 pixels, onder de drempel, en 4.000 × 3.000 pixels. Daarna hebben we elk bestand in de uploadmap twee keer gelezen, met de PHP-functie exif_read_data en met een eigen lezer die het EXIF-blok byte voor byte doorloopt. Beide kwamen bij elk bestand tot hetzelfde resultaat.

Een woord over de afbeeldingseditor. WordPress verwerkt afbeeldingen met de PHP-extensie GD of met Imagick, en kiest Imagick als beide beschikbaar zijn. In Playground valt de keuze op GD, omdat de Imagick-extensie daar geen versienummer meldt en op de controle van WordPress stukloopt. Voor de Imagick-kolom hebben we daarom de Imagick-editor van WordPress zelf afgedwongen en alleen die controle overgeslagen. Het rekenwerk deed ImageMagick 7.1.1.

Wat WordPress uitlevert

GPS betekent: breedte- en lengtegraad stonden ongewijzigd in het bestand. Schoon betekent: geen EXIF-blok meer.

De eerste rij is de kern van dit artikel. Is de lange zijde van een foto niet groter dan 2.560 pixels, dan maakt WordPress geen verkleinde versie met het achtervoegsel -scaled. Het bestand op volledige grootte is dan de foto zoals hij is geüpload, welke editor er ook draait. In de code heet de drempel big_image_size_threshold, en standaard staat hij op 2.560. Een foto van 12 megapixels (4.032 × 3.024) ligt erboven, terwijl een foto die voor het uploaden is verkleind of bijgesneden eronder kan liggen. Of de metadata dat verkleinen overleven, hangt af van het programma.

De tweede bevinding zit in de Imagick-kolom. De Imagick-editor van WordPress verwijdert bij het verkleinen wel profielen, maar zondert er uitdrukkelijk vijf uit: icc en icm voor de kleuren, iptc voor het auteursrecht, xmp voor gebruiksrechten en exif voor de oriëntatie. GPS staat in het EXIF-blok, dus blijft het in elk formaat staan. Het filter image_strip_meta zet alleen deze opschoning aan of uit. We hebben beide gemeten, met hetzelfde resultaat. GD gooit de profielen toch al weg: zo staat het in de broncode van WordPress, en zo zagen we het ook in onze meting.

Onder GD vonden we één uitzondering: een kleine foto die alleen rechtop staat dankzij een draai-instructie in zijn EXIF, draait WordPress bij het uploaden en slaat hem opnieuw op als -rotated. Die versie was schoon. Het origineel staat ook hier ernaast.

Waar het origineel op je site opduikt

Een origineel in de uploadmap zou half zo erg zijn als niets ernaar verwees. Bij de kleine foto verwijst WordPress er op meerdere plekken naar, zonder dat iemand bewust de volledige grootte kiest. We hebben de HTML gemeten die WordPress voor een afbeeldingsblok uitvoert:

• srcset: Ook als je de afbeelding kleiner invoegt, bijvoorbeeld 1.024 pixels breed, noemt WordPress in de srcset het origineel als versie van 1.600 pixels. Tot 2.048 pixels breed neemt het de volledige grootte daarin op (filter max_srcset_image_width). Welk bestand de browser ophaalt, hangt af van schermbreedte en pixeldichtheid. Hoe WordPress srcset en afbeeldingsformaten verder instelt, staat in ons artikel over lazy loading in WordPress.
• Vergroten door te klikken: De lightbox van het afbeeldingsblok laadt het bestand op volledige grootte, bij de kleine foto dus het origineel.
• Link naar het mediabestand: Bij een afbeeldingsblok net als in een galerij gaat de link naar de volledige grootte.
• Volledige grootte: Wie de afbeelding zo invoegt, sluit het origineel rechtstreeks in.

Bij de grote foto noemde de srcset alleen tussenformaten tot 2.048 pixels, en de lightbox wees naar het -scaled-bestand. Naar het origineel van 4.000 pixels linkt WordPress nergens in de HTML. Het staat wel in dezelfde map, en het adres is dat van het -scaled-bestand zonder dat achtervoegsel. Wie het ene kent, kent ze allebei. De bestandsnaam geeft WordPress zelfs zelf prijs: de openbare REST API onder /wp-json/wp/v2/media noemt hem in het veld original_image, in onze meting ook voor bezoekers die niet zijn ingelogd.

Wat Heckgalerie 1.2.6 daaraan verandert

Heckgalerie is onze galerijplugin in de WordPress-directory. Het EXIF-filter zit er sinds versie 1.0.0 in. Het geldt voor elke JPEG die in de mediabibliotheek komt, niet alleen voor galerijafbeeldingen, en het staat standaard aan. Versie 1.2.6 staat sinds 12 oktober 2026 in de directory. Waarin Heckgalerie verschilt van andere galerijplugins, staat in onze vergelijking van alternatieven voor NextGEN Gallery.

Ligt een foto onder de drempel, dan zet Heckgalerie nu naast het origineel een opgeschoonde kopie met het achtervoegsel -web en maakt die tot het bestand op volledige grootte, zoals WordPress dat anders met -scaled doet. Vanaf dan wijzen srcset, de lightbox van het afbeeldingsblok, Heckgalerie-galerijen en nieuw ingevoegde afbeeldingen naar de kopie. Het -scaled-bestand en alle tussenformaten schoont Heckgalerie ter plekke op, ook op servers waarvan de editor de metadata meesleept.

We hebben dezelfde meting herhaald met het directorypakket van Heckgalerie 1.2.6, onder GD en onder Imagick. Daarna droeg geen enkel uitgeleverd bestand nog GPS. De weg via de browser uit het kader over de blokeditor hebben we met Heckgalerie niet gemeten. De kopie van de kleine foto was 309 bytes kleiner dan het origineel: precies het EXIF-blok en een commentaar dat GD bij het maken van de testfoto had geschreven. De beeldgegevens daarachter waren byte voor byte gelijk. Heckgalerie rekent dus niets opnieuw uit, het laat alleen de metadatasecties weg.

Wat er blijft en wat niet, staat in de broncode. Het kleurprofiel blijft, net als de Adobe-markering zonder welke CMYK-afbeeldingen verkeerde kleuren tonen. Weg gaan EXIF, XMP, IPTC en commentaren, plus voorbeeld- en tweede afbeeldingen die sommige telefoons achter de eigenlijke foto hangen en die eigen GPS-gegevens kunnen dragen.

Er gelden drie grenzen:

• Alleen JPEG. PNG en WebP gaan ongewijzigd door.
• Het origineel blijft. Heckgalerie raakt het geüploade bestand niet aan. Het staat nog in de uploadmap, bij de kleine foto onder de naam zonder -web. Bij nieuwe uploads verwijst de HTML van de pagina er niet meer naar. De REST API noemt de naam wel nog in het veld original_image, en iedereen die het adres kent, kan het nog ophalen.
• Uit te zetten. De schakelaar staat in de instellingen van Heckgalerie. Wil je de metadata in de uitgeleverde bestanden houden, zet hem dan uit.

Bestaande uploads: wat het opnieuw genereren van miniaturen oplevert

Foto's die voor versie 1.2.6 zijn geüpload, schoont Heckgalerie op zodra hun miniaturen opnieuw worden gegenereerd, bijvoorbeeld met wp media regenerate. We hebben dat nagebootst met een foto van 1.600 pixels die voor de activering in vijf berichten was ingevoegd: één keer op volledige grootte, één keer 1.024 pixels breed en drie keer 1.024 pixels breed met een link naar het mediabestand, als afbeeldingsblok, in een Galerij-blok en in de klassieke editor.

Na het opnieuw genereren toonde de kleiner ingevoegde afbeelding zonder link in haar srcset de opgeschoonde kopie zonder dat iemand het bericht had bewerkt, omdat WordPress de srcset pas bij de weergave berekent. De afbeelding op volledige grootte en alle drie de links wezen nog steeds naar het origineel met GPS, omdat hun adres vast in het bericht staat. De changelog zegt dat voor afbeeldingen op volledige grootte, maar noemt de links niet. De oplossing: de afbeelding of galerij één keer opnieuw invoegen of de link opnieuw zetten. Het adres van het mediabestand is vanaf dan dat van de kopie, en in onze test wezen opnieuw ingevoegde afbeeldingen daarheen.

Zulke berichten vind je met het zoekveld in het berichten- of pagina-overzicht, dat ook de inhoud doorzoekt. Typ daar de bestandsnaam van het origineel, bijvoorbeeld foto.jpg. In onze test vond de zoekfunctie zo de afbeelding op volledige grootte en alle drie de links, en liet ze de kleinere afbeelding zonder link weg. Zoeken op size-full, de klasse die WordPress zowel in de blokeditor als in de klassieke editor aan afbeeldingen op volledige grootte hangt, vindt zulke afbeeldingen voor alle foto's tegelijk, maar geen links. Beide zoekopdrachten dekken alleen berichten en pagina's: afbeeldingen in widgets of in templates van de site-editor vind je zo niet.

Zonder Heckgalerie: controleren en handelen

Welke editor draait er?

Onder Tools → Sitediagnose, tabblad Informatie, toont het veld Actieve editor in de sectie Media afhandeling welke afbeeldingseditor er draait: WP_Image_Editor_Imagick of WP_Image_Editor_GD. Bij Imagick geldt de rechterkolom van de tabel, met het voorbehoud uit het kader over de blokeditor.

Eén bestand controleren

Open een foto van je site op volledige grootte, via de lightbox of de link naar het mediabestand, en sla hem op. Onder Windows zie je via rechtsklik op het bestand, dan Eigenschappen en het tabblad Details, of er een sectie GPS met breedte- en lengtegraad is. Het eigenschappensysteem van Windows, waaruit dit tabblad leest, gaf voor onze testfoto de coördinaten en voor de tussenformaten uit de GD-meting niets. Staat er een CDN of een afbeeldingsoptimalisator voor je site, dan controleer je zo diens uitvoer, niet het bestand op de server. Voor de bestanden op de server is de regel in de volgende sectie.

Alle bestanden in één keer vinden

Met WP-CLI geeft één regel de lijst van alle JPEG's in de uploadmap die coördinaten dragen. Hij heeft de PHP-extensie exif nodig:

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; } }'

In onze test met 26 bestanden noemde hij precies de acht met GPS: het origineel van een kleine foto, het origineel van een grote achter -scaled en een onder Imagick geüploade foto met zijn vijf tussenformaten.

Handelen

Opschonen voor het uploaden. Alleen zo komen de coördinaten nooit op de server. Onder Windows: rechtsklik, Eigenschappen, tabblad Details en onderaan de link om eigenschappen en persoonlijke gegevens te verwijderen, met de optie om een kopie te maken waaruit alle mogelijke eigenschappen zijn verwijderd. Controleer de kopie daarna zoals hierboven. Op de telefoon kun je de camera zo instellen dat hij de locatie niet opslaat.

Op Imagick-servers GD voorrang geven. Eén filter in een eigen kleine plugin of in de functions.php van een childthema zet GD vooraan, en Imagick blijft beschikbaar voor formaten die GD niet aankan:

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

Bestaande formaten worden pas schoon als je de miniaturen opnieuw genereert, zo hebben we het gemeten. Aan de originelen en aan kleine foto's op volledige grootte verandert de wissel niets. Ook bij foto's in HEIC-formaat, zoals sommige telefoons ze opslaan, helpt hij niet: GD kan HEIC niet lezen, dus verwerkt WordPress ze volgens de broncode verder met Imagick. En GD gooit ook kleurprofielen weg: foto's in een andere kleurruimte dan sRGB kunnen er in de tussenformaten iets anders uitzien.

Bestaande bestanden opschonen. Wat de WP-CLI-regel hierboven vindt, kun je met een tool als ExifTool direct op de server opschonen, na een back-up. Verwijder daarbij alleen de GPS-gegevens, bijvoorbeeld met exiftool -gps:all= -overwrite_original. Zonder -overwrite_original laat ExifTool naast elk bestand een kopie achter die eindigt op _original, en die kopie draagt de coördinaten nog. Verwijder de originelen niet en laat hun overige gegevens staan: volgens de broncode berekent WordPress nieuwe formaten uit het origineel en zet het ze rechtop volgens de draai-instructie in de EXIF.

Veelgestelde vragen