JFIF.
The oldest block in the file, holding pixel density and very little else — with a namesake sharing its marker that carries a thumbnail.
JFIF (JPEG File Interchange Format) is the conventional container header, carried in an APP0 segment identified by JFIF\0. It records a version, the pixel density units and values, and optionally a tiny embedded thumbnail. JFXX, identified by JFXX\0, is a separate extension block under the same marker whose purpose is to carry a thumbnail.
What it is
JFIF was the agreement that turned JPEG from a compression standard into a file format people could exchange. Most JPEGs still start with one, and some older decoders expect to find it.
Why it matters
The density fields are weakly fingerprintable — an unusual DPI narrows down the software that wrote the file — but they are also harmless in most contexts and removing them can affect how an image is sized when printed or placed. That trade lands on the side of keeping it by default.
JFXX is a different question with the same marker. Its reason for existing is the thumbnail, so it is dropped unconditionally. Treating the two as one because they share APP0 is precisely the mistake identifier-based classification exists to avoid.
--strict, with the reason density is weakly fingerprintable. JFXX is always dropped, with the reason embedded thumbnail. Two identifiers, one marker, opposite verdicts.
Related terms
Common questions.
Should I use --strict to drop JFIF?
Only if the weak fingerprint matters to you more than predictable sizing. It is a genuinely marginal call, which is why it is a flag rather than a default.
Will a JPEG open without a JFIF segment?
Essentially always. A few old decoders are fussier, which is the other half of the reason it is kept by default.
Get ScrubPony
Strips identifying metadata out of JPEGs without touching a pixel. C99, no dependencies beyond libc, macOS and Linux, MIT-licensed.