GPS data in photos: what WordPress serves for small images, and how to remove it

Cameras and phones write more into an image file than the image: make and model, capture time, exposure and, if location is switched on, the place where the photo was taken as latitude and longitude. All of this sits in the EXIF block at the start of the file. Whoever loads the photo loads the block with it.

WordPress itself never shows this information. In the database it stores camera, aperture, shutter speed and capture time, and coordinates are not among the fields it reads. That reassurance comes too early, because the coordinates are in the file, and the file goes to every visitor.

The gap this post is about was in our own gallery plugin as well. Up to version 1.2.5, Heckgalerie only cleaned the full-size file when WordPress had created it itself, such as -scaled for large photos. Small photos therefore went out with GPS, for example in the lightbox, and on servers with Imagick the intermediate sizes did too. Version 1.2.6 closes both gaps. For this post we first measured what WordPress serves without any plugin.

How we measured

WordPress 7.1.3 with PHP 8.3 in WordPress Playground, on 12 October 2026. The test photo is a JPEG we generated ourselves, with an EXIF block: camera make, model, capture time and GPS coordinates in Hamburg. We uploaded it through the same server-side processing that runs for uploads to the media library, in two sizes: 1,600 × 1,200 pixels, below the threshold, and 4,000 × 3,000 pixels. Then we read every file in the uploads folder twice, with PHP's exif_read_data function and with our own reader that walks the EXIF block byte by byte. Both gave the same result for every file.

A word on the image editor. WordPress processes images either with the PHP extension GD or with Imagick, and picks Imagick when both are available. In Playground the choice falls on GD, because the Imagick extension there reports no version number and fails the WordPress check. For the Imagick column we therefore forced the WordPress Imagick editor and skipped only that check. The work was done by ImageMagick 7.1.1.

What WordPress serves

GPS means latitude and longitude were in the file unchanged. Clean means no EXIF block left.

The first row is the core of this post. If the longer side of a photo is no more than 2,560 pixels, WordPress does not create a scaled-down version with the -scaled suffix. The full-size file is then the photo exactly as it was uploaded, whichever editor runs. In the code the threshold is called big_image_size_threshold, and its default is 2,560. A 12-megapixel photo (4,032 × 3,024) is above it, while one that was resized or cropped before upload can be below. Whether the metadata survives the resizing depends on the program.

The second finding is in the Imagick column. The WordPress Imagick editor does strip profiles when resizing, but it explicitly keeps five: icc and icm for color, iptc for copyright, xmp for usage rights and exif for orientation. GPS lives in the EXIF block, so it stays in every size. The image_strip_meta filter only switches this stripping on or off. We measured both, and the result was the same. GD drops profiles anyway. That is what the WordPress source code says, and it is what we saw.

We found one exception under GD: a small photo that only stands upright through a rotation tag in its EXIF is rotated by WordPress on upload and saved again as -rotated. That version was clean. The original sits next to it here too.

Where the original shows up on your site

An original in the uploads folder would be half as bad if nothing pointed to it. For the small photo, WordPress points to it in several places, without anyone deliberately choosing full size. We measured the HTML that WordPress outputs for an image block:

• srcset: Even when you insert the image smaller, say 1,024 pixels wide, WordPress lists the original in the srcset as the 1,600-pixel version. It includes the full size there up to 2,048 pixels wide (filter max_srcset_image_width). Which file the browser fetches depends on screen width and pixel density. How WordPress sets srcset and image sizes otherwise is covered in our post on lazy loading in WordPress.
• Enlarge on click: The image block's lightbox loads the full-size file, so for the small photo, the original.
• Link to the media file: On an image block as in a gallery, the link goes to the full size.
• Full Size: Inserting the image at this size embeds the original directly.

For the large photo, the srcset listed only intermediate sizes up to 2,048 pixels, and the lightbox pointed to the -scaled file. WordPress links the 4,000-pixel original nowhere in the HTML. But it sits in the same folder, and its address is that of the -scaled file without the suffix. Know one, and you know both. WordPress even gives out the file name itself: the public REST API at /wp-json/wp/v2/media names it in the original_image field, in our measurement also for visitors who are not logged in.

What Heckgalerie 1.2.6 changes

Heckgalerie is our gallery plugin in the WordPress directory. It has had the EXIF filter since version 1.0.0. The filter applies to every JPEG that enters the media library, not just gallery images, and it is on by default. Version 1.2.6 has been in the directory since 12 October 2026. How Heckgalerie differs from other gallery plugins is covered in our comparison of NextGEN Gallery alternatives.

If a photo is below the threshold, Heckgalerie now places a cleaned copy with the suffix -web next to the original and makes it the full-size file, just as WordPress otherwise does with -scaled. From then on, srcset, the image block's lightbox, Heckgalerie galleries and newly inserted images point to the copy. The -scaled file and all intermediate sizes are cleaned in place, also on servers whose editor carries the metadata along.

We repeated the same measurement with the directory package of Heckgalerie 1.2.6, under GD and under Imagick. Afterwards no served file carried GPS. We did not measure the browser path from the box on the block editor with Heckgalerie. The copy of the small photo was 309 bytes smaller than the original: exactly the EXIF block plus a comment GD had written when creating the test photo. The image data behind it was identical byte for byte. So Heckgalerie recomputes nothing, it only leaves out the metadata sections.

What stays and what goes is in the source code. The color profile stays, and so does the Adobe marker without which CMYK images show the wrong colors. Removed are EXIF, XMP, IPTC and comments, plus preview and secondary images that some phones attach behind the actual photo and that can carry GPS data of their own.

Three limits apply:

• JPEG only. PNG and WebP pass through unchanged.
• The original stays. Heckgalerie does not touch the uploaded file. It remains in the uploads folder, for a small photo under the name without -web. For new uploads, the page HTML no longer refers to it. The REST API still names it in the original_image field, though, and anyone who knows the address can still fetch it.
• It can be switched off. The switch is in the Heckgalerie settings. If you want to keep the metadata in the files that are served, turn it off.

Existing uploads: what regenerating thumbnails achieves

Photos uploaded before version 1.2.6 are cleaned by Heckgalerie once their thumbnails are regenerated, for example with wp media regenerate. We reproduced that with a 1,600-pixel photo that had been inserted into five posts before activation: once at full size, once 1,024 pixels wide, and three times 1,024 pixels wide with a link to the media file, as an image block, in a Gallery block and in the classic editor.

After regenerating, the image inserted at the smaller size without a link showed the cleaned copy in its srcset without anyone editing the post, because WordPress computes the srcset at output time. The full-size image and all three links still pointed to the original with GPS, because their address is fixed in the post. The changelog says so for full-size images, but does not mention links. The fix: insert the image or gallery once more, or set the link again. From then on the media file address is that of the copy, and newly inserted images pointed to it in our test.

You can find such posts with the search box in the posts or pages list, which also searches the content. Enter the original's file name, such as photo.jpg. In our test this found the full-size image and all three links, and skipped the smaller image without a link. Searching for size-full, the class WordPress adds to full-size images in both the block editor and the classic editor, finds such images for all photos at once, but no links. Both searches only cover posts and pages, so images in widgets or in Site Editor templates will not show up.

Without Heckgalerie: check and act

Which editor is running?

Under Tools → Site Health, Info tab, the Active editor field in the Media Handling section shows which image editor is running: WP_Image_Editor_Imagick or WP_Image_Editor_GD. With Imagick, the right-hand column of the table applies, with the caveat from the box on the block editor.

Check one file

Open a photo from your site at full size, through the lightbox or the link to the media file, and save it. On Windows, right-click the file, then choose Properties and the Details tab to see whether there is a GPS section with latitude and longitude. The Windows property system this tab reads from returned the coordinates for our test photo and nothing for the intermediate sizes from the GD run. If a CDN or an image optimizer sits in front of your site, though, this checks its output, not the file on the server. For the files on the server, use the line in the next section.

Find all files at once

With WP-CLI, one line lists every JPEG in the uploads folder that carries coordinates. It needs the PHP exif extension:

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 our test with 26 files it named exactly the eight with GPS: the original of a small photo, the original of a large one behind -scaled, and a photo uploaded under Imagick together with its five intermediate sizes.

Act

Clean before uploading. This way the coordinates never reach the server in the first place. On Windows: right-click, Properties, Details tab, then at the bottom “Remove Properties and Personal Information” and “Create a copy with all possible properties removed”. Check the copy afterwards as described above. On a phone, the camera can be set not to save the location.

On Imagick servers, prefer GD. One filter in a small plugin of your own or in a child theme's functions.php puts GD first, and Imagick stays available for formats GD cannot handle:

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

Existing sizes only become clean once you regenerate thumbnails, which is how we measured it. The switch changes nothing for originals or for small photos at full size. Nor does it help with photos in HEIC format, as some phones save them: GD cannot read HEIC, so according to the source code WordPress keeps processing them with Imagick. And GD drops color profiles too: photos in a color space other than sRGB can look slightly different in the intermediate sizes.

Clean existing files. What the WP-CLI line above finds can be cleaned directly on the server with a tool such as ExifTool, after a backup, for example with a backup plugin. Remove only the GPS data, for example with exiftool -gps:all= -overwrite_original. Without -overwrite_original, ExifTool leaves a copy ending in _original next to each file, and that copy still carries the coordinates. Do not delete the originals, and leave their other data in place: according to the source code, WordPress computes new sizes from the original and turns them upright using the rotation tag in the EXIF.

Frequently asked questions