To flip a picture, load it, press Flip Horizontal or Flip Vertical, and download the result. The flip reverses the picture across one axis: left and right swap, or top and bottom swap. It does not resize anything, so a 1600 by 1200 photo is still 1600 by 1200 afterwards, with the same number of pixels in it.
What does change is the file wrapped around those pixels. The export gets a fixed name, the byte size moves because the picture is re-encoded, and the metadata is left behind. Those three are the parts people are surprised by, so they are worth knowing before you hit download rather than after.
A flip relocates pixels inside the same frame. It does not resample them, which is why the operation on its own costs no sharpness: every pixel that went in is still there, sitting at its mirrored coordinate. Nothing is stretched to fill a gap, and nothing is cropped to make one.
| Property | Horizontal flip | Vertical flip |
|---|---|---|
| Width and height | Unchanged | Unchanged |
| Pixel count | Unchanged | Unchanged |
| Detail and sharpness | Unchanged by the flip | Unchanged by the flip |
| Transparency in PNG or WebP | Kept | Kept |
| Which way the subject faces | Reversed left to right | Reversed top to bottom |
Only the last row is supposed to move. If anything else in that table shifts, the cause is somewhere between loading and saving rather than in the flip itself.
The picture comes through intact. The file around it does not, because the export re-encodes it from scratch. Three things change, and all three are easy to miss until you go looking for the download you just saved.
Two of the three output formats are lossy, so the tool shows a quality control for those and hides it for the third. PNG is lossless: there is no quality value to apply, so the slider is not offered while PNG is selected. Exported at 50% and at 100%, a PNG comes out the same size both times, byte for byte. That is the format behaving correctly, not a stuck control.
Phone cameras frequently store a picture the way the sensor read it and attach an orientation flag telling the viewer to turn it a quarter turn. Browsers honour that flag, so the picture looks upright on screen while the stored file is still landscape. When a browser tool flips it, the rotation is applied to the pixels on the way in, so the exported picture is upright and no longer needs the flag — and no longer has one.
That is worth remembering the next time a file reports landscape dimensions while looking perfectly portrait. The flag was doing the work, and the flip has now baked that work into the pixels.
We ran the flipper on this site in a desktop Chromium browser and recorded what came back out, because the questions people actually ask about flipping a picture are about the file rather than the operation. The test set was five files: a 1600 by 1200 JPEG photo, an 800 by 800 PNG logo with a cut-out background, a 1024 by 768 WebP, a two-frame 400 by 300 animated GIF, and a 1200 by 900 BMP.
All five flipped, and all five came back at exactly the dimensions they went in at. That sounds like a low bar, but it is the property that matters most: no crop, no resize, no padding. The BMP makes the point plainly — 3,240,054 bytes in, and out came a PNG of 24,656 bytes at the same 1200 by 900.
The byte sizes are where the surprises live. The JPEG photo went in at 46,304 bytes. Exported as PNG it came back at 108,914 bytes, more than twice the source, because PNG is lossless and this picture has the smooth gradients that PNG stores badly. Exported as JPG at the default 92% it came back at 26,554 bytes, smaller than the file we started with. WebP at 50% produced 7,452 bytes.
Pushing the slider to 100% is the expensive move. JPG went from 18,983 bytes at 50% to 26,554 at the 92% default to 70,060 at 100%. WebP went from 7,452 bytes at 50% to 496,824 bytes at 100% — roughly seven times the 100% JPG and about sixty-seven times its own 50% setting. A 100% WebP export of a photograph is not a small file, and picking it out of habit is one way to end up with a download far bigger than the picture you started with.
PNG ignores the slider completely. The same photo exported at 50% and at 100% produced two files of 108,914 bytes, identical in size and identical in content. The control is hidden when PNG is selected, which is the honest way to present a setting that cannot do anything.
Flipping is exactly reversible, and we checked rather than assumed it. Each of the five files was flipped horizontally, downloaded, loaded back in, and flipped horizontally again. The second output matched the original pixel for pixel in all five cases. So if you pick the wrong direction, the fix is one more click on the same button, not a fresh upload of the original.
Transparency behaved the way the format rules predict, and we confirmed the numbers rather than the marketing: the cut-out logo kept a full 0-to-255 alpha range in both PNG and WebP output, while the JPG output had no alpha channel at all. The animated GIF came out as a single-frame PNG — the second frame is simply gone, not merged.
Metadata does not survive the export. We opened the outputs and counted EXIF entries: zero in the PNG, zero in the JPG, zero in the WebP. For a phone photo that means the orientation flag is gone too, which is harmless because it was applied to the pixels first. A 1200 by 800 JPEG carrying an orientation flag of 6, meaning rotate a quarter turn clockwise, loaded as 800 by 1200 on screen and exported as 800 by 1200, upright, with no flag left to interpret.
What we did not test, and will not claim: HEIC, AVIF, TIFF, RAW and PSD. The file picker does not accept them and we did not try to force them through, so this article says nothing about them. We did not time flips on very large files, because any figure would describe our machine rather than the tool. And we did not run this on a phone browser, so every number above describes desktop Chromium and nothing else.
The flip itself does not. It moves existing pixels to mirrored positions instead of resampling them, so no detail is invented or averaged away. Any loss comes from the export step: saving a JPG as JPG re-compresses it, and repeating that cycle on the same file erodes it a little each time.
The export uses a fixed name for every picture, so the original filename is not carried over. Flip several pictures in a row and the downloads folder ends up with flipped, flipped (1), flipped (2) and so on, which is why renaming straight after the download saves confusion later.
No. Width and height stay exactly as they were, and so does the pixel count. A 1600 by 1200 photo exports at 1600 by 1200 whichever direction you flip it.
Phone cameras often store the picture sideways and attach an orientation flag telling the viewer to turn it. The browser applies that flag when it loads the picture, so the flip happens on the upright pixels and the export comes out the right way up. If a file reports landscape dimensions while looking portrait, the flag is doing the work.
No. The export writes new pixels only, so camera EXIF, capture date, GPS coordinates and the original colour profile are not carried into the new file. We counted zero EXIF entries in the PNG, JPG and WebP outputs of our test pictures.