Just a minute...(/)
We are currently optimizing your images. Please wait a moment as we ensure the highest quality results for you.
Great, we have successfully compressed your images.
Images Optimized.
We are currently optimizing your images. Please wait a moment as we ensure the highest quality results for you.
Images Optimized.
Most people meet the .jfif extension by accident. You right-click a picture on a web page, save it, and Windows hands you a file ending in .jfif that half your other programs then refuse to open. Before anything else about compression: a .jfif file is a JPEG file. The bytes are the same and the same decoder reads them. Only the letters after the dot differ. Compressing one is compressing a JPEG, and this page does that without asking you to pick settings you have no way to judge.
JFIF stands for JPEG File Interchange Format. It is a short header that sits at the very front of nearly every JPEG ever written: the four characters J, F, I and F, right after the file's opening two bytes, followed by a version number and the pixel density. Your ordinary .jpg photos carry it too. The extension only comes out as .jfif when the program doing the saving reads the file type from the Windows registry and picks that spelling instead of .jpg. Chrome on Windows is the common cause.
We checked this instead of assuming it. Saving one image twice, once as .jpg and once as .jfif, gave two files with the same SHA-256 hash down to the last byte. The extension is a label on the outside. Nothing inside is different, which is why renaming a .jfif to .jpg usually just works.
Three things, and none of them is the size of your picture. The encoder rebuilds the quantisation tables, which is where most of the saving comes from: it spends fewer bits on detail your eye does not track. It recalculates the Huffman tables for your specific image instead of reusing a generic set. Then it writes the file as a progressive JPEG rather than a baseline one, so the picture arrives in increasing sharpness as it loads instead of painting from the top down.
It leaves the pixel dimensions alone. We put a 1400 by 900 image in and read 1400 by 900 back out of the returned file's own header. Nothing gets scaled down to make the percentage look better.
JPEG compression throws information away, and a second pass throws away a little more. That is true of every tool that shrinks a JPEG, this one included. The honest description is not "no quality loss" but "loss you are unlikely to see at normal viewing size". If the file is going to print, or into an archive you will edit again later, keep the original and compress a copy. If it is going onto a web page or into an email, the trade is almost always worth making.
On 8 September 2026 we ran four files through this page and wrote down the byte counts of what came back.
| File | Original | Returned | Change |
| Photo saved at high quality, 1400 by 900 | 383,921 bytes | 68,321 | -82.2% |
| The same photo carrying EXIF, GPS and a colour profile | 250,843 bytes | 67,501 | -73.1% |
| A file already compressed and already progressive | 64,502 bytes | 64,502 | 0% |
| A PNG dropped on this page | 703,830 bytes | 74,379 | -89.4% |
The second file in that table was built on purpose to carry passengers: a camera make, a software tag, a user comment, GPS coordinates and an embedded colour profile. We searched the returned file for all five and found none of them. What came back was a plain JFIF header, the quantisation and Huffman tables, and the picture. If you are posting a photo from a phone, that means the place it was taken does not travel with it.
This cuts both ways, and it is worth knowing which way you want. A colour profile is metadata too, and it leaves with the rest. For photographs headed to a web page that is the sensible outcome. If you work to a managed colour workflow, compress a copy and keep the original.
The third row is the interesting one. That file had already been compressed hard and already written progressively, so there was nothing left to take. It came back at exactly 64,502 bytes, the same number it went in at. A tool determined to report a win would have had to throw away picture quality to manufacture one. This one hands your original back and tells you it found nothing.
These are two different problems and it saves time to separate them. If an app rejects your .jfif, it is almost never because the picture is broken. It is because the app checks the extension against a list and .jfif is not on it. Compression does not change that: what comes back is still a .jfif, and the same app will still turn it away. The fix is to give the file the name the app expects, which is what the converter linked at the bottom of this page does. Compress when the file is too heavy. Convert when something refuses to read it.
The uploader on this page also accepts PNG, JPG, JPEG, WEBP, AVIF, GIF, SVG, TIFF and BMP. Each file comes back in the format it arrived in. The PNG in the table above went in as a PNG and came out as a PNG, still 1400 by 900, still a PNG when we read its header. Landing on the JFIF page does not quietly convert your other images into something else.
If a program still refuses your file because of its extension, JFIF to JPG gives it the name it expects. To send a set of them as one document, use JFIF to PDF. And if you want the hidden data gone without re-encoding the picture at all, Remove Photo Metadata does only that.