November 9, 2026
How to Strip Supplier Photo Metadata Before a Shopify Handoff
Inspect and remove EXIF, GPS, and hidden metadata from supplier product photos before sharing or uploading them to Shopify.
How to Strip Supplier Photo Metadata Before a Shopify Handoff
Supplier product photos can carry more than pixels: camera details, timestamps, GPS coordinates, editing notes, and other embedded metadata. Before I forward a sample to a client, a freelancer, or a Shopify content queue, I inspect it and make a deliberately clean copy. The practical answer is simple: check the original first, remove metadata only from the shareable derivative, then keep the untouched source in your asset archive.
That is not a claim that every photo is dangerous. Most of the time, the metadata is harmless. The point is that an ecommerce handoff is where a private supplier asset starts travelling through email, chat, DAMs, and storefront tools. It deserves a tiny gate.

What I am checking before the handoff
Image metadata is information stored alongside the image data. EXIF (Exchangeable Image File Format) commonly records camera make, lens, exposure, and capture time. A phone photo may also include GPS coordinates. XMP fields and comments can carry editing or workflow information. None of that changes the product image itself, but it can matter once the file leaves the supplier relationship.
For this pass I use Image Metadata Viewer from Tiny Online Tools. It accepts JPEG, PNG, and WebP files and shows EXIF fields, including GPS data when present. The site describes its utilities as browser-based, with no accounts or tracking; for a small one-off review, that is a useful fit for files I do not want to send to another random converter.
This is separate from visual QA. I still check crop, color, dimensions, and product accuracy. In fact, my earlier product-photo sample checklist is the broader gate. Metadata is one row in that checklist—not a replacement for it.
The metadata preflight I use
Here is the short version I can hand to an operator:
| Check | Why it matters | Action |
|---|---|---|
| GPS/location | Can reveal a shooting or supplier location | Remove from the outgoing copy unless the location is intentionally public |
| Timestamps | Can expose timing that is irrelevant to a product listing | Keep only when it supports your internal archive |
| Camera and software fields | Usually benign, occasionally noisy in client handoffs | Leave in the source; remove from the shareable derivative |
| ICC color profile | Can affect color rendering | Do not remove blindly; test the resulting image in the channel that matters |
| Filename and visible pixels | Not metadata, but still part of the handoff | Review separately before publishing |
The important trade-off is the ICC profile. A blanket “strip everything” rule is easy, but a product photo that shifts color after cleanup is not a win. Tiny Online Tools says its Remove Image Metadata tool removes EXIF, GPS, ICC color profiles, XMP, and comments. That means I treat the output as a new derivative that needs a quick visual check—not a replacement for the supplier original.

My browser workflow, step by step
-
Duplicate the supplier file first. Keep the original in the supplier or source folder. Name the derivative for its purpose, such as
sku-1234-main-share.jpg; do not overwrite the asset you may need to trace later. -
Inspect a representative sample. Open Image Metadata Viewer and look for location data, timestamps, camera/software fields, and anything your team would not expect in a public or broadly shared file. If a delivery contains hundreds of images, start with the formats and shooting sources that are likeliest to carry phone metadata.
-
Decide whether metadata removal is actually needed. For an internal design review, you may retain it. For a client sample, public press kit, marketplace upload, or contractor handoff, I usually create a clean copy. The decision is about the audience and file path, not a superstition about EXIF.
-
Remove metadata from the copy. Use Remove Image Metadata. The tool supports JPEG, PNG, and WebP and can process multiple images. For JPEG output, its quality setting is another reason to inspect the result rather than assuming it is identical.
-
Re-open the derivative and inspect again. Verify the metadata fields are gone as expected. Then view the image at the size and medium you will actually use: Shopify media, a client PDF, an email attachment, or a shared folder.
-
Run the normal merchandising checks. Confirm the product is not cropped badly, the background is correct, and the filename maps to the right SKU. If the source is a RAW capture, use a separate preview and acceptance step; this supplier RAW-photo workflow is a good reminder that an embedded preview is not the same thing as a final listing asset.
A failure mode worth avoiding
The bad workflow is “strip metadata from the folder and move on.” It breaks down when the stripped file becomes the only copy, a profile change alters color, or the team loses the original capture context needed for a dispute or re-edit.
The safer pattern is:
source archive → inspect → create shareable derivative → strip if needed → re-check → publish or send
This gives you a reversible decision. The original remains an archival record; the outgoing file is tailored to its audience. It also avoids confusing metadata cleanup with image optimization. If the real problem is file weight, use a compression workflow; if the real problem is a distracting background or inaccurate exposure, fix the pixels and document that editorial change. A useful companion read is this guide to relighting product photos without misrepresenting them.

When I would not strip metadata
There are legitimate reasons to keep it. A photographer may need capture data for retouching. A compliance or chain-of-custody process may need original files. A color-managed print workflow may rely on a profile, and an internal archive benefits from a faithful source.
In those cases, do not turn privacy cleanup into a destructive operation. Make the sharing rule explicit: original files live in the archive; clean derivatives go to the storefront or external recipient. That one convention is easier to teach than a long exception list.
Put the check where work already happens
I do not want an elaborate DAM approval just to share one product sample. I want a small, repeatable preflight beside the existing Shopify handoff. Tiny Online Tools makes that practical: inspect the file, clean the derivative when the audience calls for it, and move on without installing another desktop utility.
Start with your next supplier sample: keep the original, inspect one image for GPS and other hidden fields, create a clean derivative only where it earns its keep, and record that rule in the handoff checklist.