Rotate a JPEG losslesslyTurn a JPEG, keep every detail
Quarter turns and mirrors that leave the photo's quality exactly as it was.
or drop it here — pasting works too
A JPEG from a phone or a scanner is the useful case: those are the files that carry a tag.
No photo handy?
FreeNo sign-upPhotos stay on your device
Turn or mirror a JPEG by moving its compressed blocks — no decode, no second generation — and see the proof on your own file.
The tag is read before any control appears, and the reading is shown in words rather than as a number between one and eight.
What happens when you press save
A JPEG stores its picture as 8×8 blocks of compressed numbers. A quarter turn or a mirror only moves those blocks and rearranges the numbers inside each one, so nothing has to be decoded and nothing is rounded again. This page does that in the tab, writes the file, then reads its own output back and checks every block against the original before it says “written without loss”. If any check fails, it says so and re-encodes instead.
Before you save, it tells you whether a perfect turn is possible: a picture whose width or height is not a whole number of blocks on the edge the turn moves needs that strip trimmed (at most 15 pixels), or it is re-encoded and labelled a second generation. The measured difference between the two routes is in the four-turn experiment.
Checks before replacing the original
- Keep the original until the turned copy has been opened in the program or portal where the old one looked wrong.
- If only the tag is wrong and the pixels are upright, use the tag-only rewrite: it changes two fields and copies everything else byte for byte.
- The orientation tag in the written file is 1, so no viewer turns it a second time.
Questions about a lossless turn
Why must the width divide by 16?
A JPEG is stored in blocks of 8 × 8 pixels, grouped into units of 16 on any axis where colour is subsampled — which is most camera JPEGs. A turn that moves the right or bottom edge to the left or top has to move whole blocks. If that edge is a partial block, it cannot land in the right place exactly, so the page offers to trim that strip (at most 15 px) or to re-encode instead. Which edge matters depends on the turn: 90° clockwise moves the bottom edge, 90° anticlockwise the right edge, 180° both.
How do I know it really was lossless?
After the file is written, the page decodes its own output back to compressed coefficients and compares every one with the expected arrangement of the original's. Only an exact match is reported as written without loss, along with the number of blocks compared. It then also decodes both files to pixels in the browser and compares them; that check has a small fixed tolerance because browser decoders round slightly differently when the axes swap.
Why is the file a slightly different size?
The picture data is the same, but it is re-packed: the compression tables are rebuilt for this picture, and a progressive JPEG is written back as baseline. That usually moves the size by well under one percent in either direction.
When is rewriting only the tag the right repair?
When the stored pixels are already upright but the orientation field tells compliant viewers to turn or mirror them. The tool describes the field before offering either repair. If the pixels themselves are sideways and the destination ignores tags, turn the blocks instead.
Why is the embedded thumbnail unlinked?
A stale EXIF thumbnail can keep showing the old direction after the full image is repaired. Unlinking it makes file managers regenerate a preview instead of preserving the contradiction.
Lossless Jpeg