- All supported privacy metadata covered by the active handler
- Supported descriptive fields, artwork and thumbnails
- Old PDF revisions through full rewrite
- Supported archive and package timestamps
HONEST LIMITS
What metadata removal cannot promise
A responsible metadata cleaner should state what it does not remove. KillMetadata verifies supported carriers, but it does not call a file “100% metadata-free” when information can exist in visible content, unsupported structures or systems outside the file.
THE CLEANING PLAN
Remove what exposes you. Keep what makes the file work.
Every reported field is shown before the rewrite and classified by action and coverage.
- Functional data needed for appearance and playback
- Structural file information
- Document content unless explicitly classified as metadata
- The original source file
- Visible text, faces, voices and landmarks
- Steganography and forensic remnants outside supported carriers
- Secure erase and filesystem xattrs
- Hidden Office content, attachments and embedded objects as a general redaction service
- Files outside active input, output, memory, entry-count, expansion or recursion limits
WHY THE ENGINE MATTERS
Partial and rejected are product features
A partial result means known removable fields were handled but coverage is incomplete or user-supplied text intentionally remains as metadata. The reason is shown, and download requires confirmation. A rejected result never becomes downloadable.
Detected encrypted or password-protected PDFs and ZIP-based documents or archives, macro/ActiveX package signals, DRM/CENC media and unsafe offset or extent graphs are rejected. Signed PDFs are rejected before cleaning. Supported package signatures and supported C2PA carriers require explicit confirmation because cleaning removes or invalidates them.
Limits are device- and handler-specific: ordinary Blob workflows top out at 256 MiB on typical desktop devices, 128 MiB on lower-memory desktops and 64 MiB on mobile, while handlers can set lower caps. PDF input is preflight-capped at 32 MiB desktop / 16 MiB mobile; cleaned output uses the same post-return acceptance cap, and the 64 MiB qpdf report check also occurs after the raw API has materialized the result.
Explore the complete verification methodology →BEFORE YOU SHARE
A four-step privacy check.
Metadata cleaning is one part of a safe sharing workflow.
- 01Review visible content separately
- 02Inspect comments, revisions and hidden Office content
- 03Understand signature and provenance consequences
- 04Check filesystem and cloud-copy behavior after saving
QUESTIONS, ANSWERED
Know the boundary before you clean.
No vague “100% clean” claim.
Are my files uploaded?
No. The cleaner runs in your browser, has no upload endpoint, and only enables the file picker after its processor assets are available locally.
Is the original file changed?
No. KillMetadata reads the original and creates a separately named cleaned copy. It never overwrites the source file.
Does “verified-clean” mean 100% metadata-free?
No. It means no supported privacy metadata remains under full handler coverage. Visible content, steganography, filesystem attributes and previously shared copies remain outside that guarantee.
Why preserve some metadata?
Orientation, color, timing, codec headers, accessibility and required package fields can be necessary for the file to display, play or validate correctly.
Runs locally in your browserReady to inspect your file?
Inspect this file type The picker opens only after offline protection is active.