Keep the picture, leave its private labels behind
Remove common descriptive and identifying containers from a PNG or JPEG without decoding, resizing or recompressing its image data. The cleaned copy is assembled locally from the original file's retained byte ranges.
A PNG or JPEG up to 50 MB. The file structure is cleaned directly; the image is never decoded, recompressed or uploaded.
Results are provided as-is, with no warranty of accuracy. The method and its sources are published below so you can check the working.
How it works
What is removed
A PNG and a JPEG are containers around encoded image data. Both can carry information that is not needed to reconstruct the picture: descriptions, software names, timestamps, camera settings, comments and—in an EXIF container—possibly GPS coordinates.
The personal setting removes the known containers most likely to hold that material:
| Format | Removed blocks | Retained image payload |
|---|---|---|
| PNG | tEXt, zTXt, iTXt, eXIf, tIME | IDAT and animated fdAT chunks |
| JPEG | APP1, APP13 and COM segments | Everything from each start-of-scan header through its encoded scan |
Maximum cleanup goes further. It drops unknown PNG ancillary chunks unless they are on the rendering allow-list, and drops JPEG APP segments except JFIF, ICC-profile and Adobe colour-transform blocks. Critical PNG chunks and JPEG coding tables, frames and scans are never classified as disposable metadata.
Why the file is not recompressed
Re-encoding a JPEG would create another lossy generation even if its quality slider used the same number. It is also unnecessary: T.81 gives application and comment segments their own marker-delimited lengths, so a complete segment can be omitted while the later scan remains untouched.
PNG is similarly chunked. Each chunk carries a length, a four-letter type, its
payload and a CRC. Removing one whole ancillary chunk does not require opening
or recompressing IDAT. Every retained chunk—including its existing CRC—is
copied in the order in which it arrived.
A worked PNG example
The test fixture is a one-pixel PNG with two metadata chunks:
| Part | Bytes |
|---|---|
| Complete source | 100 |
tEXt chunk (Author=Ada) | 22 |
eXIf chunk | 16 |
| Cleaned output | 62 |
The result reports 2 metadata blocks and 38 bytes removed. The 62-byte
output is exactly the same signature, IHDR, IDAT and IEND byte sequence
that the fixture has when those two chunks are absent. No pixel operation is
involved.
What the two scopes mean
Known personal metadata is the conservative default. It removes containers whose defined purpose is descriptive metadata while leaving unfamiliar ancillary data alone.
Maximum compatible cleanup is useful when an application has written a private non-rendering block. Compatibility is still the operative word: colour-space, transparency, physical-size and animation chunks remain. “Maximum” does not mean “prove anonymous,” and it does not mean “discard everything except pixels.”
If file size is the real goal, use an image resizer or format converter after cleaning. If you need evidence that the downloaded copy did not change later, calculate its file checksum after the final operation.
How it is done
- Identify PNG by its eight-byte signature or JPEG by its start-of-image marker, then walk the file's declared chunks or marker segments.
- Omit known text, EXIF, time and comment containers. Maximum cleanup also omits unknown non-rendering ancillary or application blocks while retaining colour and animation structures.
- Copy every retained range in its original order, including PNG image-data chunks and the complete JPEG entropy-coded scan.
- Report the complete blocks and bytes omitted, then offer a separate same-format file rather than changing the selected source.
What it assumes
- The source is a structurally complete PNG or JPEG no larger than the stated 50 MB input limit.
- Personal cleanup targets known metadata containers; it cannot prove that identifying material is absent from pixels, filenames, cloud copies or an unknown retained block.
- ICC colour profiles, PNG colour information, transparency, physical pixel size and APNG animation control are retained because removing them can alter presentation.
- Retained chunk CRCs and scan bytes are copied rather than revalidated or repaired; this is a metadata cleaner, not a damaged-image recovery tool.
Common questions
Does removing image metadata reduce picture quality?
This cleaner never decodes or re-encodes the picture. PNG IDAT and fdAT chunks and JPEG scan bytes are copied byte for byte, so the operation introduces no new compression loss.
Does this guarantee that a photo contains no location information?
It removes the EXIF container that commonly carries GPS fields, but no file-only cleaner can certify the pixels themselves, a filename, another copy or every private format extension. Review the cleaned file in the system where it will be shared when the risk is important.
Why can the cleaned image look almost the same size?
Metadata is often tiny beside the encoded pixels. A large photograph may lose only a few kilobytes because this tool preserves its dimensions, quality and compressed image stream rather than trying to make it smaller.
Why is the ICC profile kept?
An ICC profile describes how colour samples should be displayed. It is rendering information rather than ordinary authorship or location text, and removing it can visibly change a wide-gamut image.