What matters most when cleaning a PNG
- PNG metadata can live in text chunks, Exif data, embedded colour profiles, timestamps, and other ancillary chunks.
- The safest public-release workflow is usually to export a fresh copy from pixels, then verify that the new file is clean.
- ExifTool is useful for repeatable batch work, but it does not guarantee that every possible ancillary chunk is removed.
- For digital asset management, keep the master asset intact and create a stripped delivery copy for external use.
- Always re-check the file after cleaning; do not assume a save command removed everything.
What PNG metadata actually contains and why it matters
According to the PNG specification, text can live in tEXt, zTXt, and iTXt chunks, and modern files can also carry an eXIf chunk. In practice, that means a PNG can expose captions, author names, copyright notices, software names, creation times, and sometimes camera metadata. I also treat iCCP colour profiles and pHYs pixel density hints as part of the same housekeeping problem, even though they are not always privacy risks.
| Data type | Typical purpose | My default choice |
|---|---|---|
tEXt, zTXt, iTXt
|
Descriptions, authorship, copyright, software notes, captions | Strip from delivery files, keep only if the text is intentionally part of the asset record |
eXIf |
Exif-based camera and capture data | Remove for public sharing if it is not needed |
iCCP |
Embedded ICC colour profile | Keep when colour fidelity matters, remove only with a deliberate policy |
tIME |
Last-modification timestamp | Remove if build timing is sensitive |
pHYs |
Pixel density or print hint | Keep for layout and print workflows, otherwise treat as optional |
The practical takeaway is simple: some data is useful for production, some is useful for provenance, and some should not leave the building. Once you know which is which, choosing a cleaning method becomes much easier, and the next decision is whether to strip, re-export, or rebuild the file entirely.
The safest ways to strip PNG metadata
I usually choose the method by audience, not by tool. A one-off social asset can be exported in a desktop editor, a bulk archive job is better handled from the command line, and a highly sensitive image should be rebuilt into a fresh file rather than lightly edited.
| Method | Best for | Strength | Watch out for |
|---|---|---|---|
| Export from a desktop editor | Single files and controlled creative handoffs | Simple and visual | Some apps still keep useful colour data on purpose |
| ExifTool | Repeatable batch clean-up | Fast and scriptable | It is not a universal erase button for every ancillary chunk |
| Rebuild from clean pixels | High-trust public delivery | Strongest confidence that the new file is detached from the old metadata history | Needs a proper export review |
Export from a desktop editor
This is my first choice when the image is already open in a production app and I need a clean delivery copy. Use an export or save-a-copy path that lets you control metadata, then check whether the editor is preserving the colour profile intentionally. That distinction matters: a colour profile is not the same thing as a personal identifier, and deleting both blindly can change how the PNG renders.
Use ExifTool for repeatable batch work
ExifTool is the best general-purpose command-line option when the same rule has to be applied across many files. A minimal example looks like this:
exiftool -all= -overwrite_original image.pngIt is fast and scriptable, but I would not treat it as a magical erase button. ExifTool notes that for PNG, deleting all metadata removes only XMP, EXIF, ICC_Profile, and native PNG textual data chunks; that is useful, but it is not the same as deleting every possible ancillary chunk in the format.
Read Also: DAM-CMS Integration - Avoid Hidden Costs & Boost Publishing
Rebuild the file from clean pixels
If I need the strongest confidence, I open the image from a trusted source and export a new PNG rather than editing the existing file in place. This is the closest thing to starting from zero because the new file is generated from the pixels, not from the metadata history attached to the old file. For confidential assets, that extra step is often worth the time.
Once the file has been cleaned, the real question becomes what actually disappeared and what may still be lurking in the image container.
What gets removed and what can stay behind
People often assume that "strip metadata" means the same thing in every tool. It does not. PNG is built from chunks, and some tools delete only the common metadata containers while leaving other ancillary chunks alone if they are not part of the chosen clean-up rule.
The PNG specification also allows any number of text chunks to appear, and more than one chunk can use the same keyword. That means a file can carry repeated or layered notes, which is one reason I never trust a single save operation as proof that everything has been removed.
| Chunk or data | What it can reveal | My usual handling |
|---|---|---|
| Text chunks | Descriptions, authorship, comments, software, copyright | Remove from public files; keep only when the text is part of the asset record |
| Exif chunk | Capture-related information, depending on what was written into it | Remove unless there is a deliberate reason to preserve it |
| ICC profile | Colour-management instructions | Keep if colour fidelity matters; remove only with review |
| Timestamp data | When the image was last modified | Remove if build timing or editorial workflow should stay private |
| Pixel-density hints | Preferred print scaling or layout context | Usually keep for print or layout assets, optional for web-only delivery |
How I would handle this in a digital asset management pipeline
In a DAM environment, I treat embedded file metadata and asset-record metadata as separate layers. The PNG should not be the only place where rights, authorship, and usage notes live, because once that file is stripped or converted, those details can disappear with it.
- Keep the original master untouched.
- Store rights, provenance, and usage notes in the DAM record or a sidecar, not only inside the image file.
- Create one derivative for internal review and one stripped derivative for external delivery if the asset is leaving your control.
- Automate ingest and export checks so the policy is enforced the same way every time.
- Log exceptions when metadata is intentionally preserved, especially for print, localisation, or archive use.
This approach is more reliable than trying to make every PNG do every job. The file delivers the pixels, and the DAM carries the governance. That separation becomes even more important once you start looking at the mistakes that quietly undo the whole effort.
Common mistakes that leave traces or create new problems
The failures I see most often are not dramatic. They are small workflow mistakes that leave metadata behind or damage the asset while trying to clean it.
- Saving over the original instead of exporting a new file.
- Assuming a browser-based cleaner is safe for confidential client or internal assets.
- Removing the colour profile and then blaming the artwork when the image shifts slightly.
- Not re-opening the cleaned file to verify that the metadata is actually gone.
- Forgetting that converted PNGs can inherit text or Exif data from another format.
I always re-check the result with a metadata viewer after cleaning. That extra pass is cheap, and it catches the exact problems that are easiest to miss in a busy production queue. The final question is when you should not strip metadata at all, even if the file is technically shareable.
When stripping metadata is the wrong move
Not every PNG should be cleaned aggressively. If the file is a master asset, the metadata may be the only reliable record of creator, licensing, original capture time, or production software. In a DAM setting, I would rather keep that information in the archive master and strip only the delivery derivative than destroy the provenance trail.
There are also practical reasons to preserve some embedded data. A colour profile can protect appearance across devices, pixel-density hints can help with print workflows, and text chunks can carry translated labels or captions in international production. If you remove all of that without a policy, you may create a file that is technically cleaner but operationally weaker.
One more point matters here: stripping metadata is not the same as anonymising an asset. The image content itself, plus its dimensions and visual clues, can still expose a lot. If privacy is the goal, metadata clean-up is only one part of the process.
A cleaner PNG policy that survives production
If I were setting this up today, I would keep the master file untouched, generate a stripped PNG for distribution, and verify that the exported copy still renders the way it should. That gives you privacy where you need it and traceability where it belongs.
- Use the master for archive and audit.
- Use the stripped derivative for external delivery.
- Keep rights and provenance in the DAM, not only inside the PNG.
- Re-test colour and dimensions after every cleaning rule change.
That is the practical balance I trust most: pixels preserved, embedded clutter removed when appropriate, and asset governance kept in the system designed for it.
