JFIF → JPG is mostly a change of name: the bytes inside a .jfif are already JPEG, so the job is getting an extension that upload forms, phones and older editors recognise.
From real runs
| Element | Result | What happens |
|---|---|---|
| Pixels | Changed | The image is decoded and saved again at quality 90. A 2400×3000 portrait went from 1,641,642 to 1,351,760 bytes with a PSNR of 45.0 dB against the original, a difference you will not see at normal size. |
| File signature | Kept | Input and output both start with the JPEG marker FF D8 FF. Three of our five test .jfif files carried an Exif block instead of the JFIF header and converted the same way as the others. |
| Sideways phone photos | Changed | A shot stored as 1200×1800 pixels with EXIF orientation 6 came out as upright 1800×1200 pixels, so it no longer depends on the viewer honouring the rotation tag. |
| EXIF and GPS | Lost | Camera model, capture time and GPS position are not written to the JPG; the 7,462-byte Exif block in the portrait was absent from the output. |
| Colour profile | Lost | An embedded ICC profile is not copied into the JPG. sRGB pictures look the same; a photo tagged Display P3 or Adobe RGB is shown as sRGB afterwards and can look less saturated. |
| CMYK files | Changed | A 100×100 Adobe CMYK JPEG from a print workflow became an RGB JPG of 2,587 bytes; on screen the colours matched, but the print separation is gone. |
| Progressive encoding | Changed | The Hubble Ultra Deep Field download was progressive; the output is a baseline JPEG with optimised Huffman tables, 1,382,016 bytes instead of 3,948,961. |
The image is decoded and saved again at quality 90. A 2400×3000 portrait went from 1,641,642 to 1,351,760 bytes with a PSNR of 45.0 dB against the original, a difference you will not see at normal size.
Input and output both start with the JPEG marker FF D8 FF. Three of our five test .jfif files carried an Exif block instead of the JFIF header and converted the same way as the others.
A shot stored as 1200×1800 pixels with EXIF orientation 6 came out as upright 1800×1200 pixels, so it no longer depends on the viewer honouring the rotation tag.
Camera model, capture time and GPS position are not written to the JPG; the 7,462-byte Exif block in the portrait was absent from the output.
An embedded ICC profile is not copied into the JPG. sRGB pictures look the same; a photo tagged Display P3 or Adobe RGB is shown as sRGB afterwards and can look less saturated.
A 100×100 Adobe CMYK JPEG from a print workflow became an RGB JPG of 2,587 bytes; on screen the colours matched, but the print separation is gone.
The Hubble Ultra Deep Field download was progressive; the output is a baseline JPEG with optimised Huffman tables, 1,382,016 bytes instead of 3,948,961.
We converted our JFIF sample (53 KB) with Image engine on 2026-10-20. It took 8 ms and produced a 53 KB JPEG file, about the same size as the input. The engine raised 1 warning, listed below.
Input · sample.jfif · 53 KB
54,412 bytes
Output · sample.jpg · 53 KB
480 × 600 px, baseline
Rename the file
# Windows (Command Prompt)
ren photo.jfif photo.jpg
# macOS or Linux
mv photo.jfif photo.jpgLossless and instant because the data is already JPEG. It keeps GPS and camera tags and leaves sideways photos relying on the rotation tag.
Windows Registry (stop downloads arriving as .jfif)
reg add "HKCR\MIME\Database\Content Type\image/jpeg" /v Extension /t REG_SZ /d .jpg /fRun it in an administrator Command Prompt, then restart the browser. If .jfif names come back after a software update, check the value again.
ImageMagick
magick photo.jfif -auto-orient -strip -quality 90 photo.jpgRe-encodes like our converter does. Without -quality, ImageMagick reuses its estimate of the source quality.
The HTTP API and the MCP server run the exact engine this page uses (Image engine); the response carries the same warnings the web converter shows. Check support first with GET /api/v1/pairs?from=jfif&to=jpg.
curl -X POST https://filetypeconverters.com/api/v1/convert \
-H "Authorization: Bearer $FTC_API_KEY" \
-F "file=@input.jfif" -F "from=jfif" -F "to=jpg" \
-F 'options={"width":0}' \
--output output.jpg| Key | Applies to | Type | Default |
|---|---|---|---|
| width | Writing JPEG | number | 0 |
| height | Writing JPEG | number | 0 |
| fit | Writing JPEG | contain · cover · fill | contain |
| quality | Writing JPEG | number | 90 |
| background | Writing JPEG | string | #ffffff |
| stripMetadata | Writing JPEG | boolean | true |
On Windows the registry maps the image/jpeg content type to an extension, and some installs set it to .jfif. Chrome and Edge then use that extension for every JPEG they download. The file is a normal JPEG; setting the registry value back to .jpg fixes future downloads.
JFIF, the JPEG File Interchange Format from 1992, is the header layout most JPEG files use, so a .jfif and a .jpg hold the same kind of data. Only the extension differs, and that is what upload forms and some apps check before opening a file.
A little, because we decode and re-save the pixels: 45.0 dB PSNR at the default quality 90 on a 2400×3000 portrait, which is not visible at normal size. Renaming loses nothing, so rename when you do not need metadata removed or the photo turned upright.
Most forms compare the extension with a list such as .jpg, .jpeg and .png and never inspect the bytes. A .jfif fails that check even though its contents would have been accepted.