Flipping a photo online takes a few seconds; getting a usable file back is the part that costs people time. The flip itself is exact and keeps the full resolution of the photo you loaded. What changes is the file around it: it is re-encoded, it is renamed to flipped.png or flipped.jpg no matter what it was called before, and it lands in a downloads folder rather than your camera roll.
We measured both halves on a 6000 × 4000 photo. Saved as PNG the result was 33.6 MB and pixel-identical to a computed mirror. Saved as JPG at 92% it was 6.1 MB, with an average difference of 0.15 levels per channel. Neither is wrong — they answer different questions, and the choice is the only decision worth slowing down for.
Almost every guide to flipping a photo stops at the button. Press it, the picture turns around, done. That is accurate and it is also why people end up searching again ten minutes later for a different question: the photo is flipped, but the file they now hold is not the file they expected. It is bigger, or smaller, or named something they cannot find in the folder, or it is in the wrong app on their phone.
So this page is about the handover — what the browser gives back, what it calls it, and where it puts it. The flip maths is settled; the retrieval is where the friction is.
We took one 6000 × 4000 JPEG (6.93 MB), flipped it horizontally in a browser tab, and exported it twice. Both exports came back at the full 6000 × 4000 — nothing was downscaled on the way out.
| Output | File size | Compared with a true mirror | Reach for it when |
|---|---|---|---|
| PNG | 33.6 MB (4.8× the source) | Exact — 0 differing pixels across three sampled megapixel patches | You need the exact pixels, a transparent background, or an archive copy |
| JPG at 92% | 6.1 MB | 9–14% of pixels differ by at least one level; average 0.15 levels; worst single pixel 59 | You are sending it to someone or uploading it somewhere with a size limit |
| WebP at 92% | Smaller again | Lossy in the same way as JPG | The destination accepts WebP and you want the smallest file |
The surprise in that table is the PNG. Choosing it to "avoid quality loss" on a photo that was already a 6.9 MB JPEG produces a file nearly five times larger, because PNG is lossless and stores every pixel of a noisy photograph in full. If your source was a JPEG, the PNG cannot recover detail the JPEG already threw away — it just stops throwing away any more.
This is the detail that causes the most confusion, and it takes one sentence to state: the output is named after the operation, not after your photo. Load IMG_4821.JPG and the browser offers you flipped.png. Load a completely different photo next and it offers flipped.png again.
flipped, flipped (1), flipped (2) with no clue which photo is which.flipped.png and flipped.jpg are at least told apart.The fix is a habit rather than a setting: rename the result the moment it lands, before you load the next photo. On a phone that means renaming in Files or Downloads straight away, because once the name is generic the only remaining identifier is the thumbnail.
Everything above comes from a measurement run, not from reading other people's pages. We built a 6000 × 4000 JPEG (6,930,350 bytes) with fine grain, hard edges, coloured shapes and a text block, loaded it into the flipper on this site in headless Chromium at a 1280 × 900 viewport, flipped it horizontally, and exported PNG and JPG at 92%. Each export was then compared patch by patch against a mirror computed independently in Pillow, using three one-megapixel regions — top-left corner, bottom-right corner, and the centre. The same page was then reloaded at 390 × 844 with touch emulation to measure the phone layout.
Speed first, because it is the one number that is entirely about the machine: the preview was rendered 0.74 seconds after the file was selected, and the info line read "6000 × 4000 px · 6.61 MB (source)". That is a mid-range desktop, not a fast one.
The preview is the part worth understanding. The preview canvas carries a full 6000 × 4000 backing store, but it is laid out at 432 × 288 on the desktop viewport and 324 × 216 at 390 px wide. That is 7.2% and 5.4% of the real linear size. The picture you use to decide whether the flip is right is a fourteenth-scale rendering, so fine detail — the exact spelling on a sign, the direction of a small logo — is simply not present in what you are looking at. Check the downloaded file at 100%, not the preview.
PNG exactness: 0 differing pixels in each of the three sampled patches, 3,000,000 pixels in total, maximum absolute difference 0, output 33,586,581 bytes. There is no approximation in that path at all; the flip is a coordinate reversal and PNG stores what it is given.
JPG at 92%: 6,125,423 bytes. The flat sky patch differed on 9.3% of pixels with a maximum of 4 levels. The two textured patches differed on 10.7% and 14.1% of pixels, with maxima of 48 and 59 and means of 0.15 and 0.17 levels. Read that carefully: the average error is a sixth of one level, which no screen will show you, and the worst single pixel is off by 59 out of 255, which is a visible shift on one pixel of a hard edge. That is what JPEG does to edges, and it is why a logo on a flat background is the one case where the PNG's 33 MB is worth paying.
On naming we can be precise about what we saw and careful about what we infer. The page constructs the download name as flipped plus the extension, and we observed exactly that: flipped.png from a photo called IMG_4821.JPG, then flipped.jpg from the same photo in the other format. What we deliberately will not claim is how your phone resolves a second file with the same name — whether it appends a number, overwrites, or asks. That is browser and operating-system behaviour, it differs between platforms, and we did not test it on a real handset.
The ceiling test was the most interesting one. Rather than guess, we probed the exact object the tool draws into: a canvas at full pixel dimensions, filled, then read back. At 16384 × 16384 — 268.4 megapixels — the fill and the readback both succeeded, in three separate runs. At 20000 × 15000, 300 megapixels, the canvas accepted the dimensions, accepted the drawing command, and then returned a blank readback and an empty data URL six characters long. No exception, no warning, no error in the console. One intermediate size, 16384 × 13000 (213 megapixels), failed in one run out of four and passed in the other three, which is what memory pressure looks like rather than a clean documented limit. Width on its own is not the constraint: 65535 × 100 rendered correctly.
That silent blank is the practical takeaway. If a flipper hands you an empty or black result on an enormous photo, the file is probably fine and the canvas is probably out of area. The fix is to reduce the photo before flipping, not to re-download it.
What we did not test, stated plainly: real iPhone and Android hardware, camera-roll integration, whether iOS Safari converts a HEIC file during file selection, re-compression applied later by messaging apps, and upload-based flippers — every number here comes from a browser-side tool. We also could not push a genuine 300-megapixel photo through the tool, because the test machine has 4 GB of RAM and cannot hold one; the ceiling was measured on a canvas directly, which is the same object the flip is drawn into but not the same end-to-end path.
The layout holds up at phone width: at a 390 × 844 viewport the page did not scroll sideways at all, and the preview sat at 324 × 216 inside the column. What does not fit is the controls. On that 844-pixel-tall screen the format picker sat at 941 pixels down and the download button at 1009 pixels, on a page 1501 pixels tall — so after the flip you scroll roughly 170 pixels to reach the button, which is exactly the point where people assume nothing happened.
Where the file lands is the other half. A browser download goes to the browser's download location, which on iOS means the Files app and on Android means the Downloads folder. It does not go into Photos or Gallery. If you need it in the camera roll, you have to move or share it there yourself, and that step is the one that gets forgotten.
iPhone photos are HEIC by default, and the file picker on a browser flipper typically accepts JPEG, PNG, WebP, GIF and BMP — HEIC is not on that list. Two ways around it: set the camera to Most Compatible so new photos are saved as JPEG, or share the photo out as a JPEG before you start. Do not assume the picker will quietly accept a HEIC file; check what it offers before you have spent time on the flip.
flipped plus the extension, and that name carries nothing about which photo it came from.Not in a browser-side flipper. A 6000 by 4000 photo came back at 6000 by 4000 in both PNG and JPG. The dimensions are copied from the source image, so nothing is downscaled on the way out.
Because the tool names the output after the operation, not after your photo. The original name is not carried into the download, so IMG_4821.JPG comes back as flipped.png. Rename it straight away if the name matters.
PNG if you want the exact pixels or a transparent background, JPG if you want a file you can send. On a 24 megapixel photo the PNG was 33.6 MB and the JPG was 6.1 MB, with an average difference of about 0.15 levels per channel.
Into the browser's downloads, which means the Files app on iOS and the Downloads folder on Android, not the camera roll. You have to move or share it from there before it appears in Photos or Gallery.
The file picker on a typical browser flipper accepts JPEG, PNG, WebP, GIF and BMP, and HEIC is not on that list. Set the iPhone camera to Most Compatible, or export the photo as JPEG first, rather than assuming the picker will accept it.
The result can come back blank with no error message at all. Browsers cap canvas area at around 268 megapixels; 268.4 megapixels worked in our tests and 300 megapixels produced an empty canvas without raising an exception.