Every format note

Every note below is written next to the parser it describes and read from the same capability table the engine consults before it opens a file. Nothing here is typed into this page, so none of it can describe behaviour the code does not have.

JPEG

image/jpeg · .jpg .jpeg

Metadata lives in APP segments before the compressed image data, so cleaning and editing rewrite only those segments.
A field is written to every store this file already keeps — EXIF, the IPTC block and the XMP packet — so the three cannot end up disagreeing. An IPTC block is never created where there was none; an XMP packet is created only for a field that has nowhere else to go.
Where a JPEG carries both an IPTC block and an XMP packet, the MD5 digest the Metadata Working Group guidelines require is written with them, so other software can tell whether the IPTC was changed behind XMP’s back.
The ICC colour profile is a colour transformation table, not a set of fields. Editing its tags can invalidate the profile, and replacing it changes how the image looks — that is colour management, not metadata. It can be removed.
An embedded thumbnail is an image, not fields. What matters about it is that it can still show the uncropped original, so it can be removed; there is nothing in it to edit.
The pixel density in the JFIF header is a printing instruction rather than a description of the picture, and is left to the formats that own it. It can be removed with a full clean.
Content Credentials are never editable. They are a signed record of where a file came from, and a tool that let you write a false one would be a tool for forging provenance. Removing a credential is a different act, and that is offered.
The entropy-coded scan is copied byte-for-byte: the image is never recompressed and loses no quality.
Embedded thumbnails are removed, because they can preserve a pre-crop version of the picture.
Content Credentials (C2PA) are located in APP11 segments, including manifests split across several of them. They are reported, and removed only if you explicitly ask — a metadata clean leaves them in place.

Removable blocks: EXIF, GPS, IPTC, XMP, ICC profile, JFIF, Comments, Embedded thumbnailWritable fields: 44 (camera.make, camera.model, camera.lensMake, camera.lensModel, camera.serialNumber, camera.lensSerialNumber, capture.iso, capture.exposureTime, capture.fNumber, capture.focalLength, capture.focalLength35mm, capture.exposureBias, capture.exposureProgram, capture.meteringMode, capture.whiteBalance, capture.flash, capture.colorSpace, capture.orientation, date.original, date.digitized, date.modified, general.software, general.artist, general.copyright, general.description, location.latitude, location.longitude, location.altitude, general.keywords, general.rating, rights.webStatement, general.headline, general.credit, creator.writer, general.title, general.source, general.instructions, creator.jobTitle, location.city, location.sublocation, location.state, location.country, location.countryCode, general.comment)C2PA detectC2PA remove

PNG

image/png · .png

Text chunks (tEXt/zTXt/iTXt), tIME and eXIf are dropped; IDAT pixel data is copied unchanged.
PNG has no EXIF tradition: its text chunks are where its metadata lives, and the standard keywords — Title, Author, Description, Copyright, Creation Time, Software, Comment — are written as the fields they hold.
The ICC colour profile is a colour transformation table, not a set of fields. Editing its tags can invalidate the profile, and replacing it changes how the image looks — that is colour management, not metadata. It can be removed.
An embedded thumbnail is an image, not fields. What matters about it is that it can still show the uncropped original, so it can be removed; there is nothing in it to edit.
Content Credentials are never editable. They are a signed record of where a file came from, and a tool that let you write a false one would be a tool for forging provenance. Removing a credential is a different act, and that is offered.
PNG has no IPTC container, so no IPTC data can be present.
Editing writes an eXIf chunk, which modern viewers read but some older software ignores.
Content Credentials (C2PA) live in a caBX chunk. They are reported, and removed only if you explicitly ask.

Removable blocks: EXIF, GPS, XMP, ICC profile, PNG text chunks, CommentsWritable fields: 44 (camera.make, camera.model, camera.lensMake, camera.lensModel, camera.serialNumber, camera.lensSerialNumber, capture.iso, capture.exposureTime, capture.fNumber, capture.focalLength, capture.focalLength35mm, capture.exposureBias, capture.exposureProgram, capture.meteringMode, capture.whiteBalance, capture.flash, capture.colorSpace, capture.orientation, date.original, date.digitized, date.modified, general.software, general.artist, general.copyright, general.description, location.latitude, location.longitude, location.altitude, general.keywords, general.rating, rights.webStatement, general.headline, general.credit, creator.writer, general.title, general.source, general.instructions, creator.jobTitle, location.city, location.sublocation, location.state, location.country, location.countryCode, general.comment)C2PA detectC2PA remove

WebP

image/webp · .webp

EXIF, XMP and ICCP are separate RIFF chunks; removing them leaves the VP8/VP8L bitstream untouched.
WebP carries EXIF and XMP and nothing else, so a field that lives only in an IPTC block or a comment is not offered for this format rather than being accepted and dropped.
The ICC colour profile is a colour transformation table, not a set of fields. Editing its tags can invalidate the profile, and replacing it changes how the image looks — that is colour management, not metadata. It can be removed.
An embedded thumbnail is an image, not fields. What matters about it is that it can still show the uncropped original, so it can be removed; there is nothing in it to edit.
Content Credentials are never editable. They are a signed record of where a file came from, and a tool that let you write a false one would be a tool for forging provenance. Removing a credential is a different act, and that is offered.
The VP8X feature flags are rewritten to match the chunks that remain, so the file stays spec-compliant.
Content Credentials (C2PA) live in a C2PA RIFF chunk. They are reported, and removed only if you explicitly ask.

Removable blocks: EXIF, GPS, XMP, ICC profileWritable fields: 43 (camera.make, camera.model, camera.lensMake, camera.lensModel, camera.serialNumber, camera.lensSerialNumber, capture.iso, capture.exposureTime, capture.fNumber, capture.focalLength, capture.focalLength35mm, capture.exposureBias, capture.exposureProgram, capture.meteringMode, capture.whiteBalance, capture.flash, capture.colorSpace, capture.orientation, date.original, date.digitized, date.modified, general.software, general.artist, general.copyright, general.description, location.latitude, location.longitude, location.altitude, general.keywords, general.rating, rights.webStatement, general.headline, general.credit, creator.writer, general.title, general.source, general.instructions, creator.jobTitle, location.city, location.sublocation, location.state, location.country, location.countryCode)C2PA detectC2PA remove

HEIC/HEIF

image/heic · .heic .heif

Metadata lives in the file item store: EXIF and XMP are items, and removing one means rebuilding the table of byte offsets that says where every item in the file lives.
That table is rebuilt from where the bytes actually land, not patched afterwards — the same approach the PDF writer uses for its cross-reference index.
Every item is carried across, not only the ones this build understands: the image tiles, the thumbnail, the depth map and the gain map an iPhone photograph contains are copied byte for byte.
An item stored inside another item, or in a separate file, is refused rather than rewritten: an offset this build cannot express is an error, never a guess.
A HEIC from an iPhone carries a real ICC colour profile — Display P3, in a colr property of type prof — and it is removed by a full clean, exactly as in a JPEG. Removing one means renumbering every property association in the file, which is the same kind of work as rebuilding the item table.
A colr property of type nclx is left alone. It is eleven bytes of signalling — which primaries, transfer function and matrix — not a profile, and removing it would change how the picture looks rather than remove anything about the person who took it.
Content Credentials (C2PA) sit in a top-level uuid box. Removing one shifts everything after it, which is exactly what rebuilding the item table makes safe — so removal is now offered, and it stays a separate choice from cleaning the metadata.

AVIF

image/avif · .avif

AVIF is the same container as HEIC with a different codec inside, and one implementation covers both — checked against files from more than one encoder rather than assumed.
Every AVIF in this project’s corpus states its colour with an nclx property rather than an embedded profile, and nclx is never removed: it is how the file says its colours should be read. An AVIF that does carry a profile has it removed by a full clean, like any other format.
Content Credentials (C2PA) are detected, and removable for the same reason as in HEIC: the offsets they shift can now be rebuilt. It remains a separate choice from cleaning.

MP4

video/mp4 · .mp4 .m4v

Only the container is rewritten. The encoded video and audio are never re-encoded, so there is no quality loss and no long processing wait.
udta, meta/ilst and metadata uuid boxes are removed, and mvhd/tkhd/mdhd creation and modification timestamps are zeroed.
Chunk offset tables (stco/co64) are rewritten so playback and seeking keep working after boxes are removed.
Content Credentials (C2PA) live in a top-level uuid box. They are reported, and removed only if you explicitly ask.
Fragmented MP4 files are refused rather than rewritten: their tfhd/tfra offset tables are not rewritten by this build, so removing bytes would corrupt playback.

Removable blocks: EXIF, GPS, XMP, Container metadataWritable fields: 11 (camera.make, camera.model, general.software, general.artist, general.copyright, general.description, general.title, date.original, location.latitude, location.longitude, location.altitude)C2PA detectC2PA remove

QuickTime MOV

video/quicktime · .mov

QuickTime files use the same box structure as MP4 and are handled identically.
Apple devices store make, model, software and GPS in the meta/keys/ilst store, which is removed in full.
Content Credentials (C2PA) live in a top-level uuid box. They are reported, and removed only if you explicitly ask.

WebM

video/webm · .webm

Tags, Title, MuxingApp, WritingApp, DateUTC and SegmentUID are overwritten with EBML Void elements.
Void keeps every byte offset intact, so SeekHead and Cues stay valid and the file remains seekable.
Writing new metadata into WebM is not implemented in this build, so the editor does not offer it.
No C2PA embedding is defined for Matroska in the C2PA reference implementation, so Content Credentials are reported as not checked for WebM — which is not the same as reporting that there are none.

Removable blocks: Container metadataWritable fields: none

PDF

application/pdf · .pdf

The document information dictionary (title, author, creator, producing software, dates) and the XMP packet are both read, and both are removed by a clean.
Cleaning rewrites the file as a single generation rather than appending a correction. An appended update would leave the old values in the file, readable by anyone who looks at the raw bytes.
Removing metadata does not change the text on the pages. A name printed in a document stays in the document.
Editing writes the same value into every metadata store the file already has, so the two cannot end up disagreeing. A store the file did not have is never created.
The modification date is never written unless you change it yourself. Stamping a file with the moment it was edited here would add exactly the kind of trace this site exists to remove.
Signed, encrypted and Content-Credential-bearing PDFs are refused rather than rewritten or edited, each with an explanation of what rewriting would break.
Nothing in a PDF is executed, resolved or followed. Embedded files, JavaScript and launch actions are reported as present and left untouched.
Encrypted PDFs are reported as encrypted rather than guessed at: their metadata strings cannot be read without the password, and this build never attempts one.
A PDF can hold several generations of itself. The current values are reported, and earlier generations are reported as present — because removing metadata from such a file would not remove them.
The C2PA specification defines a PDF embedding (2.4, A.4, via embedded file streams). This build detects that a manifest is attached, from the marker the specification defines, but does not read it — and it refuses to clean a PDF while one is present rather than risk breaking bindings it cannot inspect.

Removable blocks: Document information, XMPWritable fields: 8 (pdf.Title, pdf.Author, pdf.Subject, pdf.Keywords, pdf.Creator, pdf.Producer, pdf.CreationDate, pdf.ModDate)C2PA detect

MP3

audio/mpeg · .mp3

Metadata sits in a tag block before the audio and a pile of smaller ones after it — ID3v1, APEv2, Lyrics3, TAG+. The audio frames between them are copied byte for byte and never decoded.
ID3v2.3 and 2.4 are read and written. Version 2.2 is read but not written: a file carrying one is reported and left alone rather than quietly upgraded to a version some players do not read.
A frame marked compressed or encrypted is reported as unreadable rather than guessed at, and is carried across untouched.
ID3v1 gives each field a fixed 30-byte slot. When a file carries both tags and a value is too long, the ID3v1 copy is shorter — and the result says which fields were shortened rather than leaving it to be discovered.
The Xing, Info or VBRI header in the first audio frame is metadata, and it names the encoder. It is reported and left in place: removing it breaks seeking in a variable-bitrate file, which would damage the recording to hide the name of a program.
Cover art is an image, and images carry metadata of their own. What the artwork contains is reported, and it can be removed with the rest.
No C2PA embedding is defined for MP3, so Content Credentials are reported as not checked rather than as absent.

Removable blocks: ID3 tag, ID3v1 and other end-of-file tags, Cover artWritable fields: 11 (general.title, general.artist, audio.album, date.original, audio.genre, general.comment, general.copyright, audio.track, audio.albumArtist, audio.composer, general.software)

WAV

audio/wav · .wav .wave .bwf

A WAV is a RIFF file: the audio is one chunk and the metadata sits in others beside it, so cleaning copies the samples across untouched.
The Broadcast Wave extension (bext) is where a field recorder writes the originator — routinely a person or a company — along with the recording date, time reference and coding history. It is treated as the privacy-relevant block in audio, and it can be removed.
iXML holds what a production recorder knows: project, scene, take, notes, and often the names of the crew.
RIFF INFO fields, an ID3 tag inside a RIFF chunk, an XMP packet in _PMX, and the text labels on cue markers are all read and removable.
RF64 and BW64 — a WAV extended past four gigabytes — are handled as ordinary RIFF files, with the size table they keep for that purpose carried across.
bext and iXML are reported and removable but not editable: they are fixed-layout production records, and the useful operation on somebody else’s name in them is removal.
No C2PA embedding is defined for WAV, so Content Credentials are reported as not checked rather than as absent.

Removable blocks: RIFF INFO fields, Broadcast Wave extension, iXML production metadata, ID3 tag, XMP, Cover artWritable fields: 12 (general.title, general.artist, audio.album, date.original, audio.genre, general.comment, general.copyright, audio.track, audio.albumArtist, audio.composer, general.software, audio.engineer)

M4A

audio/mp4 · .m4a .m4b .m4p .aac

An M4A is an MP4 whose tracks are sound, so the container work is the same: the encoded audio is copied through untouched and only the metadata boxes are rewritten.
The sample tables that say where each piece of audio begins are rewritten with it, which is why the file still plays and its duration is unchanged.
iTunes-style metadata lives in ilst atoms — title, artist, album, date, the encoding tool — and all of it is removable.
Cover art is an image, and images carry metadata of their own. What the artwork contains is reported and it goes with the rest.
Freeform atoms are reported by the name they give themselves — a reverse-DNS owner and a field name — and their contents are shown as they are rather than guessed at.

Removable blocks: Container metadata, Cover art, EXIF, GPS, XMPWritable fields: 17 (camera.make, camera.model, general.software, general.artist, general.copyright, general.description, general.title, date.original, location.latitude, location.longitude, location.altitude, audio.album, audio.genre, general.comment, audio.track, audio.albumArtist, audio.composer)C2PA detectC2PA remove