Rotate JFIF images by 90°, 180°, 270°, or any custom angle. JFIF is identical to JPEG/JPG — fix orientation from phones and scanners.
JFIF (JPEG File Interchange Format) is the same image format as JPEG — the file is JPEG-compressed bytes wrapped in a JFIF APP0 marker segment. Most.jfif files in the wild come from Chrome on Windows: when you right-click and "Save image as" on a image/jpeg resource, Windows looks up its registry mapping for that MIME type, and on systems where that mapping points at .jfif (a default that shipped on a number of Windows builds), Chrome saves the file with a.jfif extension even though the bytes are identical to a regular.jpg. The pixel data is JPEG, so it rotates exactly like a JPEG: the editor saves a new JPEG at the "Quality" you set (see below). Typical reasons to rotate a JFIF:
IMG_1234.jfif rotated wrong because the source already lost its EXIF orientation tag during a re-encode. Rotate the pixels to fix it once and for all.| Property | .jfif | .jpg | .jpeg |
|---|---|---|---|
| Underlying codec | JPEG (ITU-T T.81) | JPEG (ITU-T T.81) | JPEG (ITU-T T.81) |
| MIME type | image/jpeg | image/jpeg | image/jpeg |
| Mandatory file header | JFIF APP0 marker segment | Usually JFIF or Exif APP1; either accepted | Usually JFIF or Exif APP1; either accepted |
| What the extension signals | "This file carries a JFIF APP0 segment" — does not affect pixel data | Generic JPEG; viewer reads markers to know which app segment is present | Same as.jpg; the long form |
| Where it comes from | Chrome on Windows (MIME-to-extension registry pointing at.jfif), some scanner utilities | Cameras, phones, most image editors | macOS, Linux, web servers; the formally correct extension per RFC 3745 |
Lossless 90/180/270 rotate in jpegtran |
Yes (block transpose) | Yes (block transpose) | Yes (block transpose) |
| Renaming the extension changes the image? | No | No | No |
In short: the pixels in photo.jfif and photo.jpg come out of the same JPEG decoder. You can rename.jfif to.jpg right now and every viewer that accepts.jpg will accept the file. The xconvert rotator keeps the.jfif extension on output for round-trip compatibility; use JFIF to JPG if you want to switch the extension after rotating.
| Rotation | Lossless here? | Quality cost | Notes |
|---|---|---|---|
| 90 degrees clockwise | No | Tiny re-encode loss at a "Quality" of 85 or more | No interpolation; the pixels are re-encoded as a new JPEG |
| 90 degrees counter-clockwise | No | Tiny re-encode loss at a "Quality" of 85 or more | No interpolation; the pixels are re-encoded as a new JPEG |
| 180 degrees | No | Tiny re-encode loss at a "Quality" of 85 or more | No interpolation; the pixels are re-encoded as a new JPEG |
| Custom 1-3 degrees | No | Tiny re-encode loss at a "Quality" of 85 or more | Used for straightening tilted horizons; corners white in a JPG unless you pick "Black" or "Auto-crop corners" |
| Custom 45 degrees | No | Tiny re-encode loss at a "Quality" of 85 or more | Decorative effect; corners white in a JPG unless you pick "Black" or "Auto-crop corners" |
Every rotation here, including 90, 180 and 270 degrees, decodes the JFIF and saves a new JPEG at the "Quality" you set (85 by default), so there is a small re-encode loss that is invisible at normal viewing sizes; raise "Quality" toward 100 to narrow it, or save as PNG for a lossless copy of the rotated pixels. A strictly lossless 90/180/270 turn needs a command-line tool such as jpegtran. Custom angle rotations also resample, and JFIF has no alpha channel, so the empty triangular corners are filled with solid white unless you pick "Black" or "Auto-crop corners" under "Background for exposed corners".
For mirroring (left-right reversal) instead of rotation, use Flip JFIF. To trim away the white corners left by a custom-angle rotation, use Crop JFIF. For a different format, see Rotate JPG or Rotate PNG.
The pixels are identical — both are JPEG-encoded streams, both report MIME type image/jpeg, both decode with the same JPEG decoder. The only structural difference is which application marker segment appears first after the start-of-image marker: JFIF files put a JFIF APP0 segment up front (defining color space and aspect-ratio fields), while Exif-tagged JPGs lead with an Exif APP1 segment. Many real-world files contain both segments back-to-back. Renaming the extension is purely cosmetic for the bytes — but apps that filter by extension will treat them as different file types until you do.
Chrome asks Windows what extension to use for files saved with MIME type image/jpeg. Windows looks up its registry mapping (HKEY_CLASSES_ROOT\MIME\Database\Content Type\image/jpeg → Extension). On a number of Windows installs, that value points at .jfif rather than .jpg. Chrome respects whatever Windows says, so the file lands with a.jfif extension even though the bytes are pure JPEG. You can edit the registry to flip the default back to .jpg, or just rotate / use / rename the.jfif file — nothing about the image data is unusual.
Only slightly. A 90-degree turn moves pixels without interpolation, but the editor then saves a new JPEG at the "Quality" you set (85 by default), so there is a small re-encode loss that is invisible at normal viewing sizes. Raise "Quality" toward 100 to narrow it, or save as PNG for a lossless copy of the rotated pixels; a strictly lossless JPEG rotation needs a command-line tool such as jpegtran. Custom-angle rotations (1.5 degrees, 45 degrees, anything that isn't a multiple of 90) also resample the pixels.
Some legacy applications filter attachments and embedded images by file extension rather than by sniffing the bytes — a JPEG with a.jfif extension fails the extension whitelist and gets refused or rendered as a broken-image icon. The fix is either to rename.jfif to.jpg (works because the bytes are JPEG) or run the file through JFIF to JPG, which just renames the file — there is no re-encode. Modern Outlook, Office 2019+, Google Workspace, and every major mail client released since 2020 handle.jfif correctly.
Yes. Capture timestamp, GPS coordinates, ISO / aperture / shutter, camera make and model, and lens information are copied unchanged. The EXIF Orientation tag itself is rewritten to 1 (normal) after rotating so that the rotated pixels display correctly in every viewer — including the ones that ignored the original Orientation tag and caused the sideways-display problem in the first place.
JFIF's APP0 segment carries three fields the bare JPEG spec doesn't: units (pixels-per-inch, pixels-per-cm, or aspect ratio), X-density, and Y-density. Rotation itself does not change density, only orientation, and the editor keeps the print resolution (DPI) when it saves a JPG. This editor has no DPI setting, though; to change the density tag for print, use your photo or layout software.
Yes. JPEG (and therefore JFIF) does not support transparency, so the empty triangular corners created by a non-orthogonal rotation are filled with solid white when you save as JPG (the editor says so before you download), or black if you pick "Black". If you need transparent corners, keep "Transparent" and save as PNG with "Save as" — the "Keep PNG" button does it in one click; JFIF to PNG converts without rotating. If you just need the corners gone, pick "Auto-crop corners", or Crop JFIF the rotated result tightly inside the rotated frame.
Yes — drop up to 50 JFIF files at once (a mixed batch works too). The rotation angle you set applies to every file in the batch; "Download all (.zip)" saves every rotated result in one ZIP, or use "Download one by one" to save them separately.
Rotating turns the image around its center by a specified angle — text inside the image stays oriented relative to the rotation, just at the new angle. Flipping mirrors the image across an axis: a horizontal flip swaps left and right (text becomes mirror-readable / backwards), a vertical flip swaps top and bottom. A 180 degree rotation produces the same visual result as applying both a horizontal and vertical flip together, but is not the same as either flip alone. For mirroring only, use Flip JFIF.