Large portrait
- Input
- grace_hopper.jfif, 1,641,642 bytes, 2400×3000 RGB with an Exif header.
- Output
- 7,999,048-byte RGB PNG in 20 s; identical pixels to the decoded JPEG. With width 1200 the PNG was 1200×1500 and 2,660,390 bytes.
JFIF → PNG freezes a JPEG download into a lossless file, which suits editing and annotating but makes a photograph several times larger than the .jfif it came from.
From real runs
| Element | Result | What happens |
|---|---|---|
| Decoded pixels | Kept | Every decoded pixel is written without further loss, which also means the JPEG blocking and ringing already in the download are preserved, not cleaned up. |
| File size | Changed | The 1,641,642-byte portrait became a 7,999,048-byte PNG and the 352,727-byte phone shot became 3,231,331 bytes; a 54,412-byte web image became 314,115 bytes. |
| Conversion time | Changed | PNG output is compressed with an extra optimisation pass, so large photos are slow: about 20 s for the 2400×3000 portrait and 29 s for the 3100×3100 Hubble image. |
| Rotation | Changed | PNG viewers do not read JPEG rotation tags, so an orientation-6 photo is turned into upright 1800×1200 pixels before it is written. |
| ICC profile | Kept | An embedded 588-byte sRGB profile in our test file was copied into the PNG's iCCP chunk, so colour-managed apps read the same colour space. |
| Camera metadata | Lost | Exif, GPS and maker notes are not written to the PNG, whatever the stripMetadata setting. |
| CMYK input | Changed | PNG has no CMYK mode, so a print-ready CMYK photo saved as .jfif is converted to RGB first; the 29,364-byte test file became a 4,113-byte RGB PNG, with print colours shifted toward screen colours. |
| Transparency | Lost | JPEG has no alpha channel, so the PNG is fully opaque; converting does not remove a white or coloured background. |
Every decoded pixel is written without further loss, which also means the JPEG blocking and ringing already in the download are preserved, not cleaned up.
The 1,641,642-byte portrait became a 7,999,048-byte PNG and the 352,727-byte phone shot became 3,231,331 bytes; a 54,412-byte web image became 314,115 bytes.
PNG output is compressed with an extra optimisation pass, so large photos are slow: about 20 s for the 2400×3000 portrait and 29 s for the 3100×3100 Hubble image.
PNG viewers do not read JPEG rotation tags, so an orientation-6 photo is turned into upright 1800×1200 pixels before it is written.
An embedded 588-byte sRGB profile in our test file was copied into the PNG's iCCP chunk, so colour-managed apps read the same colour space.
Exif, GPS and maker notes are not written to the PNG, whatever the stripMetadata setting.
PNG has no CMYK mode, so a print-ready CMYK photo saved as .jfif is converted to RGB first; the 29,364-byte test file became a 4,113-byte RGB PNG, with print colours shifted toward screen colours.
JPEG has no alpha channel, so the PNG is fully opaque; converting does not remove a white or coloured background.
We converted our JFIF sample (53 KB) with Image engine on 2026-10-20. It took 1.1 s and produced a 307 KB PNG file, 5.8× larger than the input. The engine raised 1 warning, listed below.
Input · sample.jfif · 53 KB
54,412 bytes
Output · sample.png · 307 KB
480 × 600 px, 8-bit, colour type 2
If the .jfif is a photo of a document, PNG keeps it as pixels. To get editable text, convert the image and use the screenshot-to-text workflow, which runs AI Deep Read on PNG and JPG files.
ImageMagick
magick photo.jfif -auto-orient photo.pngFor CMYK files add -colorspace sRGB so the conversion to RGB is explicit.
Python (Pillow)
from PIL import Image, ImageOps
im = ImageOps.exif_transpose(Image.open("photo.jfif"))
im.convert("RGB").save("photo.png")convert('RGB') is what makes CMYK files work; it is a plain conversion without colour management.
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=png.
curl -X POST https://filetypeconverters.com/api/v1/convert \
-H "Authorization: Bearer $FTC_API_KEY" \
-F "file=@input.jfif" -F "from=jfif" -F "to=png" \
-F 'options={"width":0}' \
--output output.png| Key | Applies to | Type | Default |
|---|---|---|---|
| width | Writing PNG | number | 0 |
| height | Writing PNG | number | 0 |
| fit | Writing PNG | contain · cover · fill | contain |
| quality | Writing PNG | number | 90 |
| background | Writing PNG | string | #ffffff |
| stripMetadata | Writing PNG | boolean | true |
No. PNG stores exactly what the JPEG decoder produced, including compression artefacts. It only stops further loss when you edit and save the picture again.
JPEG throws away detail to stay small; PNG keeps every pixel and uses lossless compression, which cannot shrink photographic noise much. The 2400×3000 portrait grew from 1.6 MB to 8.0 MB.
No. A JFIF image has no alpha channel, so every pixel stays opaque. Removing a background needs an editor or a background-removal tool, not a format change.