What No Trace Share checks, removes and deliberately leaves alone.
Metadata cleaning is not one universal operation. JPEG, HEIC, PDF and Office documents store information differently, so No Trace Share uses format-specific rules and verifies the generated copy after cleaning.
Opens the private browser-based cleaner. Your files are processed locally on your device.
Coverage at a glance
The table below describes the current web app. “Supported removal” means No Trace Share has an explicit cleaning path for that structure. It does not mean every possible metadata block in every file is guaranteed removable.
| Format | What is inspected | Supported cleaning | Important retained / blocked items |
|---|---|---|---|
| JPEG / JPG | EXIF, GPS, XMP, IPTC, comments, AI-related records, Content Credentials/C2PA, supported ICC profile metadata. | Supported — metadata segments are removed or selectively handled; supported orientation can be preserved; supported ICC profiles can be sanitized, preserved or removed. | Visible pixels are unchanged. Removing an ICC profile can change color-managed appearance. |
| PNG | EXIF, XMP/text chunks, timestamps, AI prompt/workflow fields, Content Credentials/C2PA, supported ICC information. | Supported — supported metadata chunks can be removed; supported ICC profile metadata can be sanitized or the profile removed by choice. | Image pixels remain. Visible text in the picture and pixel watermarks are outside scope. |
| WebP | EXIF, XMP, Content Credentials/C2PA and ICC profile data. | Supported — EXIF/XMP/C2PA chunks can be removed; supported orientation may be preserved; ICC profile policy is user-controlled. | Some simple WebP containers cannot preserve a non-default orientation after metadata removal; the app warns when relevant. |
| HEIF / HEIC | Compatible still-image EXIF/XMP and supported container metadata. | Conservative support — compatible metadata can be rewritten in place without silently transcoding to JPEG. | Color profiles, thumbnails, auxiliary/depth/HDR images and encoded-bitstream metadata can remain. Unsupported structures are refused rather than guessed at. |
| Supported document metadata and selected risky structures. | Metadata-only — supported metadata can be cleaned when the document structure is safe for the bounded operation. | Visible text, link targets, embedded image metadata and other document content are not redacted. Forms, signatures, encryption, attachments or active structures can block cleaning. | |
| DOCX | Core, app and custom Office properties plus selected structures used for safety checks. | Properties cleaning — supported author/document properties can be removed or retained according to choices. | Comments, tracked changes, hidden content, custom XML and thumbnails can remain. |
| XLSX | Core, app and custom Office properties with package/relationship validation. | Properties cleaning — compatible empty property parts can be removed safely rather than leaving stale package references. | Hidden sheets, comments, custom XML, workbook content and other non-property information can remain. |
| PPTX | Core, app and custom Office properties plus package safety checks. | Properties cleaning — supported document properties can be removed or retained. | Speaker notes, comments, hidden slides, custom XML, thumbnails and visible slide content can remain. |
What “verified” means here
Original stays unchanged
Each cleaning run starts from the originally selected bytes and the latest choices. No Trace Share does not silently chain a second clean from the previous output.
The new copy is inspected again
After a supported clean, the generated bytes are reinspected. Remaining findings are shown before you save or share.
Unsupported is not disguised as success
If a structure cannot be handled safely under the current rules, the app can retain it or refuse cleaning rather than label the original as cleaned.
Technical data is separated from privacy findings
Color profiles and other decoding/display information can be technically necessary. The UI distinguishes retained technical fields from higher-risk privacy findings.
AI Traces and Content Credentials
No Trace Share can identify supported AI-related text fields, generation parameters, software/generator markers and C2PA / Content Credentials records. Explicit AI-related records are reported as AI Traces; generic Content Credentials are kept distinct because their presence alone does not prove that the visible media was AI-generated.
Read how AI Traces are detected and cleaned → Read about C2PA / Content Credentials →
Common questions
Does No Trace Share remove every piece of metadata?
No. It removes supported metadata under format-specific safety rules, reinspects the generated copy, and reports retained findings. Unsupported or risky structures can be retained or can block cleaning.
Does a clean result mean a file is anonymous?
No. Verification means the supported checks were run again against the generated copy. Visible information, pixel watermarks, unsupported structures and other signals can still remain.
Are files uploaded?
Supported inspection and cleaning run locally in your browser. Selected files are not uploaded to No Trace Share for processing.
Inspect your own file before you share it.
Open the No Trace Share workspace to see supported metadata first, choose what changes, and verify the generated copy before saving.
Clean a file nowYour selected files stay in your browser and are not uploaded to No Trace Share.