GPS-Daten in Fotos: was WordPress bei kleinen Bildern ausliefert und wie du sie entfernst

Kameras und Telefone schreiben mehr in eine Bilddatei als das Bild: Hersteller und Modell, Aufnahmezeit, Belichtung und, wenn die Standortfunktion an ist, den Aufnahmeort als Breiten- und Längengrad. Das alles steht im EXIF-Block am Anfang der Datei. Wer das Foto lädt, lädt den Block mit.

WordPress selbst zeigt diese Angaben nirgends an. In der Datenbank speichert es Kamera, Blende, Belichtungszeit und Aufnahmezeit, Koordinaten gehören nicht zu den Feldern, die es ausliest. Das beruhigt zu früh, denn die Koordinaten stehen in der Datei, und die Datei geht an jeden Besucher.

Die Lücke, um die es hier geht, steckte auch in unserem eigenen Galerie-Plugin. Bis Version 1.2.5 hat Heckgalerie nur die Datei in voller Größe bereinigt, wenn WordPress sie selbst neu angelegt hatte, etwa als -scaled bei großen Fotos. Kleine Fotos gingen deshalb mit GPS hinaus, zum Beispiel in der Lightbox, und auf Servern mit Imagick auch die Zwischengrößen. Version 1.2.6 schließt beides. Für diesen Beitrag haben wir zuerst nachgemessen, was WordPress ohne Plugin ausliefert.

So haben wir gemessen

WordPress 7.1.3 mit PHP 8.3 im WordPress Playground, am 12. Oktober 2026. Das Testfoto ist ein selbst erzeugtes JPEG mit EXIF-Block: Kamerahersteller, Modell, Aufnahmezeit und GPS-Koordinaten in Hamburg. Hochgeladen haben wir es über dieselbe Verarbeitung auf dem Server, die beim Hochladen in die Mediathek läuft, und zwar in zwei Größen: mit 1.600 × 1.200 Pixeln, also unter der Schwelle, und mit 4.000 × 3.000 Pixeln. Danach haben wir jede Datei im Upload-Ordner zweimal gelesen, mit der PHP-Funktion exif_read_data und mit einem eigenen Leser, der den EXIF-Block Byte für Byte durchgeht. Beide kamen bei jeder Datei zum selben Ergebnis.

Ein Wort zum Bildeditor. WordPress rechnet Bilder entweder mit der PHP-Erweiterung GD oder mit Imagick und nimmt Imagick, wenn beide verfügbar sind. Im Playground fällt die Wahl auf GD, weil die dortige Imagick-Erweiterung keine Versionsnummer meldet und an der Prüfung von WordPress scheitert. Für die Imagick-Spalte haben wir den Imagick-Editor von WordPress deshalb erzwungen und nur diese Prüfung übersprungen. Gerechnet hat ImageMagick 7.1.1.

Was WordPress ausliefert

GPS heißt: Breiten- und Längengrad standen unverändert in der Datei. Sauber heißt: kein EXIF-Block mehr.

Die erste Zeile ist der Kern dieses Beitrags. Ist die längere Seite eines Fotos nicht größer als 2.560 Pixel, legt WordPress keine verkleinerte Fassung mit dem Zusatz -scaled an. Die Datei in voller Größe ist dann das Foto, so wie es hochgeladen wurde, egal welcher Editor läuft. Die Schwelle heißt im Code big_image_size_threshold und steht ab Werk auf 2.560. Ein Foto mit 12 Megapixeln (4.032 × 3.024) liegt darüber, eines, das vor dem Hochladen verkleinert oder zugeschnitten wurde, kann darunter liegen. Ob die Metadaten das Verkleinern überleben, hängt vom Programm ab.

Die zweite Erkenntnis steckt in der Imagick-Spalte. Der Imagick-Editor von WordPress entfernt beim Verkleinern zwar Profile, nimmt aber fünf ausdrücklich aus: icc und icm für die Farben, iptc für das Urheberrecht, xmp für Nutzungsrechte und exif für die Ausrichtung. GPS steht im EXIF-Block, also bleibt es in jeder Größe erhalten. Der Filter image_strip_meta schaltet nur diese Bereinigung an oder aus. Wir haben beides gemessen, das Ergebnis war gleich. GD verwirft Profile ohnehin, so steht es im Quelltext von WordPress, und so sah es auch in unserer Messung aus.

Eine Ausnahme haben wir unter GD gefunden: Ein kleines Foto, das nur per Drehanweisung im EXIF aufrecht steht, dreht WordPress beim Hochladen und legt es als -rotated neu an. Diese Fassung war sauber. Das Original liegt auch hier daneben.

Wo das Original auf der Seite landet

Ein Original im Upload-Ordner wäre halb so schlimm, wenn nichts darauf zeigte. Beim kleinen Foto zeigt WordPress an mehreren Stellen darauf, auch ohne dass jemand bewusst die Originalgröße wählt. Gemessen haben wir am HTML, das WordPress für einen Bildblock ausgibt:

• srcset: Auch wenn du das Bild kleiner einfügst, etwa mit 1.024 Pixeln Breite, nennt WordPress im srcset das Original als Fassung mit 1.600 Pixeln. Bis 2.048 Pixel Breite nimmt es die volle Größe dort auf (Filter max_srcset_image_width). Welche Datei der Browser holt, entscheiden Bildschirmbreite und Pixeldichte. Wie WordPress srcset und Bildgrößen sonst setzt, steht in unserem Beitrag über Lazy Loading in WordPress.
• Vergrößern bei Klick: Die Lightbox des Bildblocks lädt die Datei in voller Größe, beim kleinen Foto also das Original.
• Link auf die Mediendatei: Am Bildblock wie in einer Galerie führt der Link auf die volle Größe.
• Originalgröße: Wer das Bild so einfügt, bindet das Original direkt ein.

Beim großen Foto nannte das srcset nur Zwischengrößen bis 2.048 Pixel, die Lightbox zeigte auf die -scaled-Datei. Das Original mit 4.000 Pixeln verlinkt WordPress im HTML nirgends. Es liegt aber im selben Ordner, und seine Adresse ist die der -scaled-Datei ohne diesen Zusatz. Wer die eine kennt, kennt beide. Den Dateinamen gibt WordPress sogar selbst heraus: Die öffentliche REST-Schnittstelle unter /wp-json/wp/v2/media nennt ihn im Feld original_image, in unserer Messung auch für Besucher ohne Anmeldung.

Was Heckgalerie 1.2.6 daran ändert

Heckgalerie ist unser Galerie-Plugin im WordPress-Verzeichnis. Den EXIF-Filter hat es seit Version 1.0.0. Er gilt für jedes JPEG, das in die Mediathek kommt, nicht nur für Galeriebilder, und er ist ab Werk eingeschaltet. Version 1.2.6 steht seit dem 12. Oktober 2026 im Verzeichnis. Wie sich Heckgalerie von anderen Galerie-Plugins unterscheidet, steht in unserem Vergleich der Alternativen zu NextGEN Gallery.

Liegt ein Foto unter der Schwelle, legt Heckgalerie jetzt neben das Original eine bereinigte Kopie mit dem Zusatz -web und macht sie zur Datei in voller Größe, so wie WordPress es sonst mit -scaled tut. Ab dann zeigen srcset, die Lightbox des Bildblocks, Heckgalerie-Galerien und neu eingefügte Bilder auf die Kopie. Die -scaled-Datei und alle Zwischengrößen bereinigt Heckgalerie an Ort und Stelle, auch auf Servern, deren Editor die Metadaten mitschleppt.

Wir haben dieselbe Messung mit dem Verzeichnis-Paket von Heckgalerie 1.2.6 wiederholt, unter GD und unter Imagick. Danach trug keine ausgelieferte Datei mehr GPS. Den Weg über den Browser aus dem Kasten zum Block-Editor haben wir mit Heckgalerie nicht gemessen. Die Kopie des kleinen Fotos war 309 Bytes kleiner als das Original: genau der EXIF-Block und ein Kommentar, den GD beim Erzeugen des Testfotos hineingeschrieben hatte. Die Bilddaten dahinter waren Byte für Byte gleich. Heckgalerie rechnet also nichts neu, es lässt nur die Metadaten-Abschnitte weg.

Was dabei bleibt und was nicht, steht im Quelltext. Es bleiben das Farbprofil und die Adobe-Markierung, ohne die CMYK-Bilder falsche Farben zeigen. Entfernt werden EXIF, XMP, IPTC und Kommentare, dazu Vorschau- und Zweitbilder, die manche Telefone hinter das eigentliche Foto hängen und die eigene GPS-Daten tragen können.

Drei Grenzen gehören dazu:

• Nur JPEG. PNG und WebP gehen unverändert durch.
• Das Original bleibt. Heckgalerie fasst die hochgeladene Datei nicht an. Sie liegt weiter im Upload-Ordner, beim kleinen Foto unter dem Namen ohne -web. Bei neuen Uploads verweist das HTML der Seite nicht mehr auf sie. Die REST-Schnittstelle nennt ihren Namen aber weiter im Feld original_image, und abrufbar bleibt sie für jeden, der die Adresse kennt.
• Abschaltbar. Der Schalter steht in den Einstellungen von Heckgalerie. Wer die Metadaten in den ausgelieferten Dateien behalten will, schaltet ihn aus.

Altbestand: was das Neuerzeugen der Vorschaubilder erreicht

Fotos, die vor Version 1.2.6 hochgeladen wurden, bereinigt Heckgalerie, sobald ihre Vorschaubilder neu erzeugt werden, zum Beispiel mit wp media regenerate. Wir haben das mit einem Foto von 1.600 Pixeln nachgestellt, das vor der Aktivierung in fünf Beiträge eingefügt worden war: einmal in Originalgröße, einmal mit 1.024 Pixeln Breite und dreimal mit 1.024 Pixeln und Link auf die Mediendatei, als Bildblock, im Galerie-Block und im klassischen Editor.

Nach dem Neuerzeugen zeigte das kleiner eingefügte Bild ohne Link im srcset die bereinigte Kopie, ohne dass jemand den Beitrag bearbeitet hätte, weil WordPress das srcset erst bei der Ausgabe berechnet. Das Bild in Originalgröße und alle drei Links zeigten weiter auf das Original mit GPS, denn ihre Adresse steht fest im Beitrag. Für Bilder in Originalgröße sagt das auch der Changelog, die Links nennt er nicht. Abhilfe: das Bild oder die Galerie einmal neu einfügen oder den Link neu setzen. Die Adresse der Mediendatei ist ab dann die der Kopie, und neu eingefügte Bilder zeigten in unserem Test darauf.

Solche Beiträge findest du mit der Suche in der Beitrags- oder Seitenübersicht, die auch den Inhalt durchsucht. Gib dort den Dateinamen des Originals ein, etwa foto.jpg. In unserem Test fand sie so das Bild in Originalgröße und alle drei Links und ließ das kleiner eingefügte Bild ohne Link aus. Die Suche nach size-full, der Klasse, die WordPress im Block-Editor wie im klassischen Editor an Bilder in Originalgröße hängt, findet solche Bilder für alle Fotos auf einmal, Links aber nicht. Beide Suchen erfassen nur Beiträge und Seiten, Bilder in Widgets oder in Templates des Website-Editors findest du so nicht.

Ohne Heckgalerie: prüfen und handeln

Welcher Editor läuft?

Unter Werkzeuge → Website-Zustand, Reiter „Bericht“, steht im Abschnitt Medienverarbeitung beim Feld „Aktiver Editor“, welcher Bildeditor läuft: WP_Image_Editor_Imagick oder WP_Image_Editor_GD. Bei Imagick gilt die rechte Spalte der Tabelle, mit der Einschränkung aus dem Kasten zum Block-Editor.

Eine Datei prüfen

Öffne ein Foto deiner Seite in voller Größe, über die Lightbox oder den Link auf die Mediendatei, und speichere es. Unter Windows zeigt ein Rechtsklick auf die Datei, dann Eigenschaften und der Reiter Details, ob ein Abschnitt GPS mit Breiten- und Längengrad dabei ist. Das Eigenschaftensystem von Windows, aus dem dieser Reiter liest, gab für unser Testfoto die Koordinaten aus und für die Zwischengrößen aus dem GD-Lauf nichts. Läuft ein CDN oder ein Bildoptimierer vor deiner Seite, prüfst du so allerdings dessen Ausgabe, nicht die Datei auf dem Server. Für die Dateien auf dem Server ist die Zeile im nächsten Abschnitt da.

Alle Dateien auf einmal finden

Mit WP-CLI liefert eine Zeile die Liste aller JPEGs im Upload-Ordner, die Koordinaten tragen. Sie braucht die PHP-Erweiterung exif:

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 unserem Test mit 26 Dateien nannte sie genau die acht mit GPS: das Original eines kleinen Fotos, das Original eines großen hinter -scaled und ein unter Imagick hochgeladenes Foto samt seinen fünf Zwischengrößen.

Handeln

Vor dem Hochladen bereinigen. Nur so kommen die Koordinaten gar nicht erst auf den Server. Unter Windows: Rechtsklick, Eigenschaften, Reiter Details, unten „Eigenschaften und persönliche Informationen entfernen“, dann „Kopie erstellen, in der alle möglichen Eigenschaften entfernt sind“. Die Kopie danach wie oben prüfen. Am Telefon lässt sich das Speichern des Standorts in der Kamera abschalten.

Auf Imagick-Servern GD vorziehen. Ein Filter in einem eigenen kleinen Plugin oder in der functions.php eines Child-Themes stellt GD nach vorn, Imagick bleibt für Formate, die GD nicht beherrscht:

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

Bestehende Größen werden erst sauber, wenn du die Vorschaubilder neu erzeugst, so haben wir es gemessen. An den Originalen und an kleinen Fotos in voller Größe ändert der Wechsel nichts. Auch bei Fotos im HEIC-Format, wie sie manche Telefone speichern, hilft er nicht: GD kann HEIC nicht lesen, WordPress rechnet sie laut Quelltext weiter mit Imagick. Und GD verwirft auch Farbprofile: Fotos in einem anderen Farbraum als sRGB können in den Zwischengrößen etwas anders aussehen.

Bestehende Dateien bereinigen. Was die WP-CLI-Zeile oben findet, lässt sich mit einem Werkzeug wie ExifTool direkt auf dem Server bereinigen, vorher mit einer Sicherung, etwa per Backup-Plugin. Entferne dabei nur die GPS-Angaben, etwa mit exiftool -gps:all= -overwrite_original. Ohne -overwrite_original legt ExifTool neben jede Datei eine Kopie mit der Endung _original, und die trägt die Koordinaten weiter. Die Originale nicht löschen und die übrigen Angaben darin lassen: WordPress berechnet neue Größen laut Quelltext aus dem Original und stellt sie nach der Drehanweisung im EXIF aufrecht.

Häufige Fragen