Metadata

Removing a watermark deletes your EXIF data — and the eraser is not what deleted it

Yes, it is gone. We built a 400 × 200 JPEG carrying a hand-written EXIF block — camera make, model, artist, copyright, date, GPS latitude and longitude — plus an XMP packet, confirmed all eight marker strings were present in the file, and pushed it through the same cycle every browser image tool uses: decode, draw to a canvas, save. Every one of those strings was absent from the saved PNG and from the saved JPEG. The saved PNG contained only IHDR, IDAT and IEND chunks. Nothing in that outcome has anything to do with removing a watermark. Painting over pixels does not touch a metadata container; re-encoding the image does, and re-encoding is unavoidable once pixels have changed. Below is exactly what we measured, which single tag does change your output file, why losing metadata is sometimes the outcome you want, and how to put it back.

Measurements on this page were taken in Chrome 153 (headless, Windows) on September 28, 2026. The test file was built in the browser by hand-writing the EXIF APP1 segment byte by byte, following the tag layout in CIPA DC-X008-Translation-2019 (Exif 2.32).

Why metadata disappears, in one sentence

EXIF, XMP, ICC profiles and PNG text chunks are containers that sit around the pixels, in segments and chunks the decoder reads and then throws away. A canvas holds a grid of decoded pixels and nothing else. So the moment an image is decoded into a canvas, the metadata is already gone — before any watermark is touched. Encoding the canvas back to a file writes a brand new container with no reason to contain anything it never received.

This is why the question is often answered confusingly online. The watermark removal step is irrelevant to it. A tool that cropped your image, resized it, rotated it, or did nothing at all would produce the same metadata-free file, because the loss happens at the decode boundary. A commenter on Hacker News put the two ideas side by side without realising they are different layers: "Most cameras already produce metadata. You can remove this metadata. Can you not also detect and remove watermarks?" Stripping metadata is a container operation, and a tool can do it perfectly while changing no pixel. Removing a watermark is a pixel operation, and doing it forces the container to be rebuilt from scratch.

What we measured

The test file was a real JPEG, 400 × 200 pixels, 9,222 bytes from canvas.toBlob at quality 0.95. We then inserted an APP1 EXIF segment — an IFD0 with Make, Model, Orientation, XResolution, Software, DateTime, Artist and Copyright, an Exif sub-IFD with ExifVersion, DateTimeOriginal and pixel dimensions, and a GPS sub-IFD with latitude and longitude — plus an APP1 XMP packet declaring a creator, creator tool and rights. The tagged file was 10,146 bytes. We confirmed the tags were really in there by searching the raw bytes for each string, then decoded the file, drew it to a canvas, and saved it as both PNG and JPEG at quality 0.92.

The GPS coordinates are not in that table because a coordinate is stored as three rational numbers rather than readable text, so a string search cannot find it. It is in the same EXIF block as everything else on the list, and that entire block is gone: the Exif signature itself is absent from both outputs, which means no APP1 segment survived at all.

The container tells the same story from the other direction. We parsed every chunk in the saved PNG: IHDR, twenty-one IDAT chunks, and IEND. There is no eXIf chunk, no tEXt chunk, no iTXt, no iCCP. Chrome writes the pixels and stops.

The one tag that does change your file: Orientation

Orientation is the exception worth knowing about, because it is the only piece of metadata that leaves a visible trace in the output. Most phone cameras write a sideways sensor image and an Orientation tag telling viewers how to turn it. Our test file stored 400 × 200 pixels with Orientation = 6 (rotate 90° clockwise). Both decode entry points returned a rotated image:

So the rotation is applied during decoding and baked into the pixels that get saved: our output file came out 200 × 400. The tag that would explain why is gone. That is the whole hazard in one line — the turn survives, the instruction that caused it does not. Nothing downstream can tell the saved file was ever sideways. We also tried passing imageOrientation: 'none' explicitly to createImageBitmap() to suppress the turn; in this Chrome build the result was still 200 × 400, so do not rely on that option. If you need the original framing, rotate the saved file afterwards.

PNG text chunks and the rest: same fate

The same test run a second time with a PNG carrying three tEXt chunks — Software, Copyright and Description — confirms the pattern is not JPEG-specific. The input was 78,857 bytes and its chunk list read IHDR, three tEXt, IDAT run, IEND. After the decode-and-save cycle the output was 78,690 bytes and its chunk list read IHDR, IDAT run, IEND. All three strings were absent.

One thing we did not test: embedded ICC colour profiles. We did not attach a real profile to a test file in this run, so this page makes no claim about how a tagged wide-gamut profile is handled during decoding, or whether colours shift. Treat that as unmeasured rather than as safe.

Pixels untouched, container rebuilt

The loss is entirely on the container side. Decoding our saved PNG and comparing it byte channel by byte channel against the pixels that went into the encoder gave a maximum absolute difference of 0 and a mean absolute difference of 0 across the whole image. A PNG-for-PNG pass through this pipeline changes no pixel value at all.

What does change is the file. Our 9,222-byte JPEG came back as a 77,560-byte PNG, roughly eight times larger, because a lossless PNG of a photographic gradient costs far more than a quality-0.95 JPEG of the same thing. That is a property of the output format, not of metadata: the output format page covers which one to pick and why. Separately, if your image is larger than the tool's working size, the saved file is a scaled copy — the home page and remove text from image work at a longest side of 1800 pixels, and remove logo from image works at a longest side of 2400 pixels.

Where each tool on this site sits in that pipeline

Both tools here end in the same final step, and it is worth naming precisely so the claim on this page is checkable against the source rather than taken on trust. The home page and the text page share app.js, which reads your file with new Image(), draws it to a canvas, and saves with canvas.toBlob(resolve, 'image/png') — always PNG. The logo page uses logo-removal.js, which also reads with new Image() and saves with canvas.toBlob(resolve, type, 0.92), where the type is the PNG, JPEG or WebP you select. Neither path reads, copies, or rewrites any metadata segment. The metadata was already gone at the decode step, and there is nothing left at the encode step to write.

A web page can still read a few facts about the file you picked, straight from the browser's File object: its name, size, MIME type and last-modified timestamp. We confirmed the timestamp comes back as a number in Chrome. None of those are written into your output either, and none of them need to be. See the privacy page for what this site does with a file while it is open.

Losing it is sometimes the point

The practical rule: if the metadata is something you need, treat this step as destroying it and plan to re-add it. If the metadata is something you would rather not publish, this step does that for you at no extra cost.

How to check it yourself

1. List what is in a file. With exiftool installed: exiftool photo.jpg. For everything including XMP and ICC: exiftool -a -u -g1 photo.jpg. An empty or near-empty result means there is no metadata, which is what you should expect from a saved file.
2. Compare before and after. Save both files side by side and run exiftool -a -u -g1 on each. The difference is the answer for your own tool and your own image, which beats trusting anyone's table — including this one.
3. Check the PNG chunk list. exiftool -v3 file.png prints the chunks it walks through. If you see only IHDR, IDAT and IEND, the file carries no text or metadata chunk at all.
4. Check the orientation hazard specifically. Run exiftool -Orientation -n before.jpg. If it returns 6 or 8, your saved file will come out turned relative to the stored pixels, with no tag left to explain it.
5. Do it without installing anything. Drag the file into a browser tab, open developer tools, and run performance.getEntriesByType('resource') if you also want to see what the page loaded — the method on the verification page uses the same idea to check whether a file was sent anywhere.

How to put the metadata back

Metadata is a container, so it can be reattached without touching a single pixel. With exiftool:

• Copy everything from the original: exiftool -tagsFromFile original.jpg cleaned.png. This is the one command that solves most cases — it moves the whole block across, including the copyright notice.
• Copy only some tags: exiftool -tagsFromFile original.jpg -Artist -Copyright -DateTimeOriginal cleaned.png. Use this when you want attribution but not the GPS coordinates.
• Write fields by hand: exiftool -Artist="Your Name" -Copyright="Copyright (c) 2026 Your Name" cleaned.png.
• Remove the GPS only: exiftool -GPS:all= cleaned.png. Useful when you want attribution to travel but not your location.

One caveat that matters: after reattaching, the Orientation tag is now wrong for a file whose pixels have already been turned. Do not copy Orientation across from a file that came out rotated — you will get a double turn. Set it explicitly with exiftool -Orientation=1 -n cleaned.png, or leave it off.

What this site does and does not do

• It does remove a visible mark from one still image at a time, in your browser, with no upload and no account.
• It does not preserve EXIF, XMP, ICC or PNG text metadata. Both tools decode into a canvas and re-encode, and in our test every metadata string was gone from the saved file.
• It does not add, edit, or fabricate metadata either. Your saved file carries no camera, author, or location fields — not false ones, just none.
• It does apply the EXIF Orientation tag during decoding, because the browser does. A file tagged Orientation 6 or 8 will be saved already turned, with the tag removed.
• Everything stays local. The verification page gives the method to confirm that with your own network panel, and the no-signup page explains what that costs you in convenience.

Figures come from a Chrome 153 headless run on Windows on September 28, 2026. The EXIF APP1 segment was written by hand following the tag layout in CIPA DC-X008-Translation-2019 (Exif 2.32, also published by JEITA as CP-3451); the XMP packet used the Adobe XMP namespace http://ns.adobe.com/xap/1.0/; the PNG text chunks used the tEXt chunk defined in the PNG Specification. The Hacker News comment is quoted from item 48200734, posted May 19, 2026. Metadata behaviour is a property of the browser's decode and encode path, not of any single site, and it can change between browser versions — the commands above let you re-check it on your own files at any time.