Re-encoding an image means decoding it into pixels and writing a new file. That can be a useful way to make a smaller share copy or reduce attached metadata, but it is not the same as copying the original bytes. The format, encoder, quality setting, dimensions, transparency, and color handling all affect the result.
For a privacy-oriented export, Unmetaimage keeps the workflow local in your browser and supports a same-format path for JPEG, PNG, and WebP. Your original stays unchanged. The goal is to make a deliberate derivative that looks right at the size where it will be used.
JPEG: efficient for photographs, sensitive to repeated lossy saves
JPEG is a lossy format designed for still images such as photographs. The MDN image format guide describes JPEG as a good choice for photographic content and warns that sharp diagrams and text can suffer under lossy compression. A JPEG export does not preserve every original pixel value, even when the visual difference is difficult to see.
If a JPEG is decoded and saved again as JPEG, the second encoder works from the first decoded result. Repeating that cycle can make block edges, fine texture, small text, and gradients look worse. To limit avoidable damage, keep the dimensions unchanged, use a high quality setting, and avoid repeated export cycles. Inspect the result at 100% around text, hair, foliage, product edges, and smooth skies.
There is no universal quality number that is correct for every photo or browser encoder. Treat the quality control as a trade-off between file size and visible artifacts. If the image is a logo, screenshot, chart, or line drawing, PNG or lossless WebP may be a better source format than JPEG.
PNG: lossless pixel compression, different file metadata
PNG is commonly used for screenshots, illustrations, UI assets, and images that need transparency. Its pixel compression is lossless, so a PNG-to-PNG export can preserve the rendered pixel values when the browser handles the image as expected. It can still produce a different file because the encoder may rewrite chunks, remove text fields, change color-profile metadata, or add its own resolution metadata.
PNG does not have a JPEG-style quality slider in the browser canvas API. The web platform requires support for image/png; if the requested type is missing or unsupported, HTMLCanvasElement.toBlob() says the browser falls back to PNG. That fallback is one reason to check the downloaded file’s actual type rather than trusting a filename alone.
Transparency needs a specific check. A PNG can contain an alpha channel. JPEG cannot, so converting a transparent graphic to JPEG requires a background decision and can change the appearance around edges. Keeping PNG as PNG avoids that format-level loss when the delivery system accepts it.
WebP: choose between lossy and lossless behavior
WebP supports both lossy and lossless compression. Google’s WebP overview explains that lossy WebP uses predictive coding and that lossless WebP reconstructs the encoded pixels exactly. WebP also supports transparency, so it can be useful for web graphics as well as photographs.
In a browser export, the quality argument applies to formats that support lossy compression, including image/webp. A high value can preserve more visible detail but may make a larger file; it is not a promise of pixel identity. If your browser or application offers a lossless WebP mode, use it for line art or transparency when exact rendered pixels matter. Otherwise, compare the output visually and keep the original for any later edit.
WebP can be smaller than JPEG or PNG for a similar visual result, but compatibility is part of quality. The MDN format guide recommends considering browser support and fallbacks when selecting an image format. A file that looks excellent but fails to display in the delivery context is not a successful export.
A same-format re-encoding checklist
- Keep the original file in an archive and work from a copy.
- Choose the same format: JPEG to JPEG, PNG to PNG, or WebP to WebP.
- Keep width and height unchanged unless resizing is part of the job.
- For JPEG or lossy WebP, start with a high quality value and compare the file size with the visual result.
- For PNG, check transparency, small text, and color after export.
- Open the downloaded file in an image viewer and a metadata viewer. Confirm the MIME type, dimensions, transparency, and fields you intended to remove.
- Inspect the image at 100% before sending it to a client, storefront, or platform.
This workflow is especially useful when the purpose is to create a clean share copy. A new encoding may drop EXIF, GPS, prompt, or software fields, but it can also write browser-specific metadata. See EXIF and GPS privacy and how to remove AI metadata for the privacy side.
What re-encoding does not solve
Re-encoding does not preserve a C2PA Content Credential automatically. It may disconnect an embedded manifest from the new asset, so keep a credentialed original when provenance matters; the C2PA guide explains why. It also does not promise to remove visible or invisible pixel watermarks, and it cannot make an image “undetectable.” For that boundary, read metadata versus invisible watermarks and AI detection.
Use the result as a checked derivative: local, same format, and appropriate for its destination. The original remains your source for future edits and higher-fidelity exports.