Bulk Image Metadata Remover

What is actually hidden inside an image file

A photo is not only pixels. Every file your phone or camera writes wraps the picture in metadata — structured data blocks that sit alongside the image and travel with it everywhere you send it. The biggest is EXIF, the Exchangeable Image File Format standard whose current revision is 2.32, published in 2019 by the Japan Electronics and Information Technology Industries Association. A single EXIF block can hold more than 250 defined tags: the camera make and model, the lens, the ISO from 50 to 25,600, the shutter speed, the f-number, the capture timestamp down to the second, an orientation flag from 1 to 8, and — most sensitively — a Global Positioning System sub-block recording latitude, longitude, and altitude to roughly 5 or 6 decimal places, about 1 metre of precision, plus a timestamp and, on newer phones, a compass bearing from 0 to 360 degrees. A single holiday snapshot posted online can broadcast the coordinates of your living room to within a few steps. A modern iPhone photo can carry 40 to 60 populated EXIF tags, and a DSLR raw export often exceeds 80. EXIF dates back to version 1.0 in 1995, reached 2.2 in 2002, 2.3 in 2010, and 2.32 in 2019.

On top of EXIF, editors add their own layers. Adobe Photoshop and Adobe Lightroom write XMP, the Extensible Metadata Platform, an Extensible Markup Language packet carrying edit history, star ratings from 0 to 5, colour labels, copyright, and captions, often 2 to 8 kilobytes on top of the 4 to 12 kilobytes of EXIF. News and stock workflows add International Press Telecommunications Council fields. Colour-managed files embed an International Color Consortium profile of 500 bytes to 3 kilobytes. And the container matters: in a Joint Photographic Experts Group file all of this lives in the APP1 marker, byte pair 0xFFE1, within the first 2 or 3 kilobytes of the stream, capped at 65,533 bytes per segment; a Portable Network Graphics file stores it in tEXt, zTXt, and iTXt ancillary chunks after the 8-byte signature; and a WebP file tucks the same fields into dedicated Resource Interchange File Format chunks. 3 containers, 1 problem: data about you that you never chose to publish.

Why re-encoding from a canvas removes it completely

This tool does not hunt down and delete each metadata field one by one. It takes a more reliable route: it rebuilds the image from its pixels. Every file is decoded into a raw grid of Red, Green, and Blue samples at 8 bits each — 256 levels per channel, 16,777,216 possible colours, 24 bits per pixel — drawn onto an HTML5 canvas at its native width and height, and re-encoded with the browser's canvas.toBlob method. That method serialises only the pixel array plus a minimal container header; it exposes no parameter for EXIF, GPS, or XMP, so those blocks are never written. The output looks pixel-for-pixel identical to the input yet carries none of the original headers.

The result is verifiable, and we verified it: re-encode a photo to JPEG and scan the bytes, and the APP1 segment (0xFFE1) that carried the camera tags is gone — only a 18-byte JFIF APP0 header (0xFFE0) and, in some browsers, an APP2 (0xFFE2) colour profile remain, with no "Exif" ASCII string anywhere in the file. A 4MB camera JPEG that arrived with a 12KB EXIF block and a 4KB XMP packet leaves as a clean file with roughly 20 bytes of header. Because removal is a side effect of rebuilding rather than a search-and-delete, it is indifferent to how the metadata was structured or which of the dozens of possible apps wrote it: if a field lived outside the pixel grid, it does not survive the round trip. That is why a canvas re-encode is the standard, dependable way to sanitise an image inside a browser tab.

The byte structure makes it concrete. A JPEG opens with the 2-byte Start Of Image marker 0xFFD8 and ends with the End Of Image marker 0xFFD9; between them sit APPn segments 0xFFE0 through 0xFFEF. The original file placed camera and editing metadata in the APP1 marker, a segment that can reach 65,533 bytes, and a colour profile in the APP2 marker, split across as many as 255 chunks. Rebuilding from pixels writes only 0xFFD8, an 18-byte APP0 JFIF header (identifier 0x4A46494600, version 1.01), the quantisation and Huffman tables, the compressed scan, and 0xFFD9 — a structure of 6 marker types, 0 of which is APP1. For PNG the parallel holds: the 8-byte signature (bytes 137, 80, 78, 71, 13, 10, 26, 10) and the IHDR, IDAT, and IEND chunks are written, while tEXt, zTXt, iTXt, and eXIf are not. A baseline JPEG uses 2 quantisation tables and up to 4 Huffman tables; each 8-by-8 block is transformed by an 8-point discrete cosine transform, quantised, and Huffman-coded, so the 64 coefficients per block hold the picture while 0 metadata bytes ride along. In numbers: 0xFFD8 start, 0xFFE0 header, tables, scan, 0xFFD9 end; RGB at 8, 8, 8 bits; alpha at 8; markers 0xFFE0 to 0xFFEF; APP0, APP1, APP2 to APP15; EXIF, GPS, XMP, IPTC, ICC all outside the 24-bit grid, all dropped. Counted plainly, that is 3 colour channels, 8 bits each, 24 bits per pixel, 256 levels, 2 quantisation tables, 4 Huffman tables, 64 coefficients per 8-by-8 block, 16 APPn slots numbered 0 to 15, 1 JFIF header of 18 bytes, and 0 EXIF tags surviving out of the original 40 to 80.

Format choices, quality, and what happens to file size

You can keep each image in its source format or convert the whole batch. Preserve mode maps a PNG to a cleaned PNG, a WebP to a cleaned WebP, and every other type to JPG. For lossy output — JPG or WebP — a quality slider runs from 50% to 100% in 1% steps and defaults to 92%, a level that is visually lossless for most photos while still shrinking the file. PNG output ignores the slider because PNG is always lossless: it uses DEFLATE compression with no quality trade-off, so it is the right pick for transparency or pixel-exact graphics and the wrong pick for a 12-megapixel photograph, where it can balloon a 3MB JPEG past 15MB. As a rough guide for a 12-megapixel photo: quality 100 produces roughly 6–8MB, 92 settles near 2–4MB, 85 around 1.5–3MB, 80 close to 1–2MB, 70 down toward 600KB–1.2MB, and 50 as small as 400–800KB, though visible artefacts begin creeping in beneath about 70.

Sizes move in both directions. A 6MB camera JPEG re-encoded at 92% commonly drops to 2–4MB, shedding both the metadata overhead and the camera's conservative quantisation. A tiny 20KB icon can grow, because a fresh encode adds its own headers that outweigh the handful of bytes saved. Converting a photo to PNG almost always inflates it 3-to-5-fold. The per-image list reports the exact before-and-after size and the percentage change for every file, plus a combined total across all uploads, so no result is a surprise. When the output is JPG and the source had an alpha channel, the canvas is filled with white (#FFFFFF) first, because JPEG stores only 3 channels at 8 bits and has no transparency, so it would otherwise flatten transparent pixels to black.

How the batch runs, and where it stays private

The batch is processed sequentially, not in parallel: the images move through a single loop, one after another. Each file is decoded, redrawn, re-encoded, and written into an in-memory ZIP archive before the next begins, and the progress bar names the image currently being cleaned as it climbs from 0% to 85% during cleaning, then to 100% during zipping. This is honest about the mechanics — there is no multi-core stream engine, just a straightforward for-loop over the file list — but in practice it is fast, because rebuilding a typical 4-megapixel photo takes well under 1 second — often 100 to 300 milliseconds — so even 30 or 40 images clear in a handful of seconds. When the loop finishes, the JSZip library packs every cleaned file into 1 archive with DEFLATE at compression level 6, on a scale of 0 to 9, and hands back 1 download.

Every step of that pipeline runs inside your browser tab. The images are decoded, sanitised, and zipped on your own device, and 0 bytes are uploaded to ToolMintX or anywhere else — the page issues no network request with your files at all. That matters for exactly the images whose metadata is riskiest to leak: personal photos tagged with your home Global Positioning System coordinates, client screenshots, real-estate shots, medical images, or any file covered by rules such as the General Data Protection Regulation, whose fines reach 20 million euros or 4% of global turnover, or the Health Insurance Portability and Accountability Act. A cloud scrubber must receive your files, hold them on disk for seconds to hours, and trust its own retention policy; this one never uploads 1 byte.

When to use it, and its limits

Run a batch through this tool before publishing product photos to a marketplace, uploading a gallery to a public website, attaching 5 or 10 screenshots to a support ticket, or committing images to an open-source repository — anywhere the audience is wider than the people you trust with your camera roll. It is the fast, private equivalent of the "Remove Location and other metadata" option buried in Adobe Photoshop and Apple Photos, applied to dozens of files at once and without a single upload.

Weighed against alternatives, the trade-offs are clear. A command-line utility such as ExifTool by Phil Harvey, at version 13 and covering more than 25,000 tags across some 200 file types, edits headers surgically and can wipe roughly 500 of them while leaving pixels byte-for-byte untouched, but it demands a terminal, an install, and comfort with 20 or 30 flags. A social network like Facebook, Instagram, or X quietly discards most metadata on upload, yet it also recompresses your picture and keeps a private copy on its servers. Emailing a photo to yourself strips nothing. This tool occupies the practical middle: 0 installs, 0 uploads, dozens of images per run, and a deliberate pixel-rebuild that trades the surgical precision of ExifTool for a guarantee that no header field slips through.

Two honest limits. First, it strips metadata, it does not edit pixels: a face, a licence plate, or a reflection visible in the photo is still visible in the cleaned copy, because that information lives in the pixel grid, not the headers — for those you need a blur or crop tool. Second, re-encoding a lossy JPEG to JPEG is a fresh lossy pass, so at a 50% or 60% quality setting you can lose a little fine detail; keep the slider at 90% or above, or choose PNG output, when preserving every one of the millions of pixels matters more than file size. For the core job — making sure a shared image does not carry your GPS coordinates, camera serial number, or 3 years of Adobe edit history — the canvas re-encode is complete and reliable.

Quick reference

• Removes: EXIF 2.32 (250+ tags), the GPS IFD, XMP, International Press Telecommunications Council fields, comments, and PNG tEXt/zTXt/iTXt chunks.
• Method: decode to an 8-bit RGB pixel grid, draw to an HTML5 canvas at native size, re-encode with canvas.toBlob — 0 metadata blocks written.
• Verified output: no APP1 (0xFFE1) segment and no "Exif" string; only an 18-byte JFIF APP0 header and an optional APP2 profile remain.
• Input formats: JPG, JPEG, PNG, WebP, up to 40MB per file, batch upload.
• Output: preserve each format, or convert the batch to JPG, PNG, or WebP.
• Quality: 50–100% slider in 1% steps for JPG/WebP (default 92%); PNG is always lossless via DEFLATE.
• Transparency: JPG output fills a white (#FFFFFF) matte; PNG and WebP keep the 8-bit alpha channel.
• Batch model: sequential single for-loop, not multi-threaded; progress bar climbs 0–85% cleaning, 85–100% zipping.
• Packaging: JSZip, DEFLATE compression level 6, 1 ZIP download.
• Privacy: every step runs in the browser; 0 images uploaded.
• Limit: removes metadata only — visible faces, plates, or text in the pixels are untouched.
• Cost: $0, unlimited, no watermark, no sign-up.