Why You Should Strip Metadata Before Uploading Images to Your Website

You should strip metadata from images before uploading them to your website because most content management systems publish what you give them. The original file, with its GPS coordinates, camera serial number and editing history, often stays reachable at a public URL, and some systems copy that metadata into every resized version. Stripping it first protects privacy, removes bytes every visitor downloads, and does not depend on how your CMS behaves this year.

Your CMS probably keeps the original file

When you upload an image, a CMS usually stores the file and generates resized versions for different layouts. What happens to metadata depends on the platform, the image library on your server and your plugins. A few verified examples, at the time of writing (2026):

• WordPress keeps the original upload in wp-content/uploads/. Resized copies made with the GD library lose their metadata, but with Imagick, WordPress intentionally keeps the EXIF, IPTC, XMP and ICC profiles in resized copies, as the source of its Imagick strip_meta method shows. Our guide on whether WordPress removes EXIF data covers this in detail.
• Image processing libraries differ in their defaults. The widely used Node.js library sharp, for example, removes all metadata by default when it writes an image, and keeps it only if the developer asks, according to its output documentation.
• Image CDNs often remove metadata from the transformed versions they generate, with options to keep copyright fields. The untransformed original you uploaded may still be served unchanged at its own URL.
• Hosted store and site builders rarely document their metadata handling, and behavior can change without notice. For Shopify and WooCommerce specifically, see our guide for e-commerce teams.

The pattern is the same everywhere: the resized image on the page might be clean, while the full-size original sits one URL away. Visitors who click "open image in new tab", scrapers and archive crawlers do not care which one you meant to publish.

The privacy case for stripping metadata from website images

Websites publish images to everyone, permanently, and to automated tools that collect them at scale. The risks that matter most on a site are different from a single social media post.

Locations you did not mean to publish

Team photos taken at someone's home, a home office used for a small business, a remote employee's headshot taken on their balcony, or a blog post illustrated with phone photos: each can carry the GPS coordinates of a private address. Your "About" page should not contain your staff's home addresses.

Links between identities

If you write under a pen name or run a site you prefer to keep separate from your personal accounts, camera metadata can connect them. The same BodySerialNumber or the same Artist name in images on two sites tells anyone who looks that one person took both.

Internal history

Edited images can carry XMP history: original file names, internal project names, the software used, and sometimes notes or keywords written for internal use. PNG files from some AI image generators store the full generation prompt and settings in text chunks. None of this belongs on a public page by accident.

Images other people send you

Much of what ends up on a website was not shot by the person uploading it. Guest authors attach photos from their phones, clients send pictures of their premises, event organizers forward crowd shots, and agencies deliver edited files with their own metadata. Whoever uploads the file becomes the one publishing its metadata. If your site publishes contributions, make cleaning part of the editorial checklist, the same way you check spelling and image rights. For organizations in the EU, this also ties into data minimisation, as explained in our article on photo metadata and the GDPR.

Search engines and archives keep copies

Removing an image from a page later does not guarantee it is gone. Image search engines, web archives and scrapers may already hold copies of the file as it was. Cleaning before the first upload is the only point at which you fully control what gets copied.

The performance case: how much metadata weighs

Metadata is not needed to display an image, but every byte of it is downloaded with the image. Where the bytes come from:

Be realistic about the gain. On a large hero image, metadata is usually a small share of the file. On a page with many small thumbnails, a fixed overhead per file matters more, because the image data shrinks with the dimensions but a camera's EXIF block and thumbnail do not.

Metadata and Core Web Vitals

Google's Core Web Vitals include Largest Contentful Paint (LCP), which is often an image. LCP depends on how fast that image arrives, so every unnecessary byte in it counts, metadata included. But the big wins come from serving images at the size they are displayed and compressing them sensibly. Stripping metadata is the easy final step on top, not a substitute.

Which metadata to keep on website images

A clean image does not mean an image with zero bytes of metadata. Some items affect how the image looks or how it is credited.

• ICC color profile. Without it, browsers assume sRGB, and photos edited in Display P3 or Adobe RGB can look dull or shifted. Our guide to ICC color profiles explains why it is worth keeping.
• Orientation. Many phone photos are stored sideways with an orientation flag telling viewers how to rotate them. Remove the flag without rotating the pixels and the image appears sideways.
• Credit and licensing fields, if you want them. Google documents reading IPTC fields such as Creator, Credit Line, Copyright Notice and Web Statement of Rights to show credits and licensing information in Google Images. It does not document any benefit from GPS or camera fields.
• AI labels, where required. Some platforms require the IPTC DigitalSourceType field on AI-generated images.

Our tool keeps exactly the first two, the ICC profile and the orientation flag, and removes everything else, including IPTC and XMP. If you want credit fields on your images, add them back after cleaning, for example with ExifTool.

A simple pre-upload workflow

1. Resize each image to the largest size your layout displays, typically around twice the CSS width for high-density screens.
2. Compress or convert to an efficient format at a sensible quality. If this step already re-encodes the image, choose the option that discards metadata if your tool offers one.
3. Strip metadata. Use our free metadata remover for up to 10 images at a time in any browser. The default "Keep same format" mode removes metadata without re-encoding the pixels, so there is no quality loss. Our article on removing metadata without losing quality explains the difference.
4. Add back what you want public, such as copyright fields.
5. Upload the cleaned files, and keep the originals in your own archive.

How to check what your site actually serves

1. Open a published page and download an image directly from the page, not from your computer.
2. In your CMS media library, find the URL of the original upload and download that too.
3. Inspect both with a metadata viewer or exiftool -a -G1 -s image.jpg.
4. Repeat for one resized version listed in the image's srcset.

Our guide on how to check that metadata was really removed shows what clean output looks like on every operating system.

Checklist

• Strip metadata from every image before upload, including images from colleagues and agencies.
• Keep the ICC profile and orientation; add credit fields back only if you want them.
• Resize and compress too; metadata removal is the last step, not the only one.
• Find out whether your CMS keeps originals and copies metadata into resized versions.
• Download and inspect a live image after any CMS, plugin or theme change.
• Replace old images that still carry GPS or serial numbers.