{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

Output:{{ resolvedFormatLabel }} Privacy markers:{{ resultsReady ? computation.values.privacy_markers_remaining : '—' }} Size change:{{ resultsReady ? formatSignedPercent(computation.values.size_change_percent) : '—' }}
{{ summaryAnnouncement }}
Image cleanup inputs
Drop, paste, or browse one browser-readable image up to 40 MB.
{{ dropzoneTitle }}
{{ dropzoneSubline }}
{{ sourceStatusAnnouncement }}

Ignored {{ ignoredFileCount }} extra file{{ ignoredFileCount === 1 ? '' : 's' }}; this workflow keeps one source tied to one receipt.

Auto resolves from the selected image. Pin a format when the destination requires JPEG, PNG, or WebP.
Keep this on for phone photos that rely on an EXIF Orientation tag.
{{ orientationEnabled ? 'Orientation applied' : 'Raw encoded orientation' }}
{{ safeQuality }}%
The 92% default favors visual fidelity; lower it for a smaller sharing copy.
Used only when the clean output is JPEG.

{{ cleanCopyAnnouncement }}

{{ chartExportStatus }}
{{ auditExportStatus }}

Sending an image can reveal more than the picture. Camera files and edited graphics may carry capture times, device details, creator names, captions, comments, editing history, embedded thumbnails, and location fields. That information can be useful in an archive or publishing workflow, yet it may be unnecessary in a marketplace listing, support ticket, school document, or public post.

Metadata lives in the image container alongside the encoded pixels. Exchangeable Image File Format (Exif), Extensible Metadata Platform (XMP), and IPTC fields commonly hold descriptive or workflow information. Formats also use technical data for color, density, transparency, and animation. Removing every non-pixel block indiscriminately can therefore improve privacy while changing color handling or other useful behavior.

Image information to review before sharing
Information Why it exists Why it deserves review
Exif, XMP, and IPTC Capture details, orientation, rights, captions, and editing workflow Names, dates, software history, or location fields may travel with the file
Comments and text chunks Notes, encoder labels, and format-specific properties Old captions or internal notes may no longer belong with the image
Technical profiles Color rendering, pixel density, and display behavior Removing or replacing them can alter appearance even when the pixels seem unchanged

A clean sharing copy is normally made by decoding the visible image and encoding those pixels into a fresh file. This avoids copying source metadata blocks forward, but it is not a forensic erasure guarantee. Unusual containers may escape a limited scan, and visible details such as faces, badges, addresses, reflections, or landmarks remain part of the pixels.

Keep the original when provenance matters. Journalism, legal evidence, medical records, asset archives, and color-managed production may depend on untouched timestamps, profiles, captions, or camera information. A separate cleaned copy supports safer sharing without destroying that record.

How to Use This Tool:

Choose one source image and decide how the fresh copy should preserve orientation, transparency, and compression.

  1. Drop, paste, or browse for one Source image. Use a browser-readable image no larger than 40 MB and no more than 60 million decoded pixels.
  2. Choose an Output format. Auto detect keeps JPEG, PNG, or WebP sources in the same format and uses JPEG for other decodable formats.
  3. Leave Apply source orientation on for photos that rely on an Exif orientation tag. For JPEG or WebP, adjust Encoding quality; for JPEG, choose the color that will replace transparent pixels.
  4. Inspect the clean preview and Metadata audit. Download the copy only after its orientation, colors, transparency treatment, and remaining privacy-marker count look right.

Interpreting Results:

Privacy markers counts recognizable Exif, XMP, IPTC, comment, and text-bearing structures. A zero count means none of those common markers were found in the clean output. It does not prove that every possible metadata parser would find nothing.

  • A GPS hint is a text screen for location-like words, not a complete coordinate decoder.
  • Technical markers are reported separately because color, density, animation, and encoder data are not automatically private.
  • Size change reflects fresh encoding as well as removed metadata. A larger output can be valid when its format or quality setting stores the pixels differently.
  • A limited source scan is a reason to verify the downloaded copy with another metadata inspector before sensitive publication.

Technical Details:

Metadata removal here is a pixel re-encoding process followed by a container scan. The decoded width and height are retained, while the destination encoder decides which new technical chunks are needed. Source metadata is not copied as a block-for-block rewrite.

Transformation Core:

  1. The source container is inspected. JPEG, PNG, WebP, and GIF receive format-aware marker scans; other decodable formats receive a limited signature scan.
  2. The browser decodes the image. Source orientation is applied when that option is enabled.
  3. The decoded pixels are drawn into a fresh image surface. JPEG output fills transparent areas with the selected background before drawing.
  4. The pixels are encoded as JPEG, PNG, or WebP. JPEG and WebP use the selected quality from 45% through 100%; PNG ignores that setting.
  5. The new file is scanned again, and source-versus-output marker counts and byte sizes form the cleanup receipt.

Animation is not preserved by this path. An animated GIF or WebP is exported as one decoded still frame. Color profiles and other technical metadata may also be replaced or omitted, so visual review remains necessary.

Formula Core:

File sizes are reported in kibibytes, and the signed percentage compares the fresh file with the source. A negative result means the clean copy is smaller.

K =B1024 ΔS =100×BoutBsourceBsource R =max(0,PsourcePout)

B is byte count, K is size in KiB, ΔS is size change in percent, P is the count of privacy-like markers, and R is the non-negative removed-marker count. Display formatting rounds sizes and percentages; the comparisons use the full byte counts.

Image metadata scan coverage
Container Privacy-oriented checks Important limit
JPEG Exif, XMP, IPTC or Photoshop data, comments, and other application segments Text sampling identifies common structures rather than decoding every tag
PNG Exif, text, compressed text, international text, and time chunks Technical ancillary chunks are counted separately
WebP Exif and XMP chunks Animation and color-profile chunks are technical markers
GIF Comment and application extensions Application extensions can also carry animation behavior
Other decoded formats Exif and XMP signatures in a limited leading-byte scan Coverage is incomplete and should not be treated as a full audit

Privacy Notes:

The source image and fresh copy are processed in the current browser and are not uploaded by this tool. Keep the original outside the sharing path, and independently inspect a high-risk output when a location, identity, legal, or safety concern depends on complete removal.

  • Metadata cleanup does not redact visible text, faces, reflections, or landmarks.
  • A zero common-marker count is evidence from the supported scans, not proof against every hidden-data technique.
  • Re-encoding can change compression, color rendering, transparency, and animation even when privacy cleanup succeeds.

Worked Examples:

Phone photo that depends on orientation

Keep Apply source orientation enabled, create the clean copy, and compare it with the source. The pixels should remain upright even though the original Exif orientation block is not carried into the new file.

Transparent graphic needed as JPEG

Choose JPEG and set the background before encoding. Transparent pixels become that solid color, so check edges and logos in the preview rather than treating metadata removal as the only acceptance test.

References: