Images & photos · Image Metadata Privacy Tool
Why Photo Metadata Adds Weight to Every Page Load on Your Website
· Why it matters
image-privacy file-formats browser-processing
Embedded thumbnails, XMP packets and MakerNote blocks travel with every image your visitors download, and they contribute nothing to what is displayed. This post explains where the weight comes from and why stripping without re-compression is a free improvement.
The product gallery that ships a second copy of every picture — how embedded EXIF thumbnails and XMP add bytes nobody sees
A web gallery can deliver an embedded EXIF thumbnail, XMP packet, comments and device records to every visitor even though none contributes to the displayed picture. The exact overhead varies by file, so the tool reports input bytes, output bytes and bytes removed instead of promising a universal saving. Privacy and transfer efficiency align when those blocks are unnecessary.
Where the bytes hide — MakerNote blobs, embedded previews, long XMP packets and duplicated IPTC data
In JPEG the removable bytes sit in APP1 Exif and XMP, APP13 Photoshop/IPTC, COM and other metadata APPn segments. PNG uses eXIf, text and time chunks. WebP uses EXIF and XMP RIFF chunks. The cleaner leaves compressed JPEG scan, PNG IDAT and WebP VP8 or VP8L data unchanged, making the source of any size reduction explicit.
Why it compounds — many images per page, repeat visitors, mobile data, and metadata that no browser uses to render the picture
A small per-file overhead repeats with every image and every download that is not served from a cache. Galleries, product grids and responsive variants can multiply that repetition, but the repository provides no traffic model or percentage claim. Measure with real files and production delivery rather than turning one sample into an industry statistic.
Compression is not the fix for this — re-compressing to save bytes trades quality; removing metadata saves bytes and changes no pixels
Recompression can make a file smaller, but that is a different optimisation with different quality and colour consequences. Metadata removal does not need to decode pixels. ToolAcre drops whole blocks and preserves rendering-critical ICC, gamma, density, transparency and colour-transform information, so its reported saving is not confused with an encoder changing the picture.
Privacy for your visitors and staff too — GPS and device data in product photos taken on a staff phone
Website images can expose staff names, camera identifiers, locations, software and timestamps as well as waste bytes. Removing those fields from publishing derivatives reduces that unneeded disclosure. It does not change information visible in products, offices or reflected screens, which still requires a separate editorial review.
Worked example: before and after on a gallery photo — comparing file sizes after stripping and confirming the image data is unchanged
Prepare one gallery image at its final dimensions and encoding, then inspect and strip it. Compare the exact byte counts shown in the cleaned report, inspect the removed and kept lists and verify the result. Perform image resizing or quality optimisation before this final pass, because a later editor export can write metadata back into a clean file.
What this does not cover — server-side build pipelines and CDN transformations; this post is about files you prepare by hand
This browser tool prepares individual files and does not crawl a website, rewrite a content management system or guarantee that an image CDN will preserve the cleaned bytes. It accepts files up to 50 MB and rejects unsupported formats. Check the deployed resource itself after the rest of the publishing pipeline has run.
Takeaway: strip before upload — the Image Metadata Privacy Tool removes the metadata blocks without re-encoding, so the picture stays as sharp as you exported it
Strip before upload, but measure instead of marketing the result as free universal performance. The defensible benefit is the exact number of metadata bytes removed from each file while compressed picture data stays unchanged. Repeating that deterministic preparation across a gallery avoids transferring private blocks that the page never uses.