Open a PNG, JPG, WebP or AVIF and save it in another format, using the codecs your browser already ships. Drop in a whole folder, set the quality once, and save the lot.
Drop images here, or click to choose
PNG, JPG, WebP, AVIF, GIF, BMP, SVG. As many at once as you like. HEIC opens in Safari only.
Free · no sign-up · nothing uploaded. Your files are decoded and re-encoded on your own device, so a photo with a face or a location in it never leaves the machine.
One file or thirty, dragged onto the box or picked from it. There is no upload step, so a 20 MB photo opens as fast as a small one.
Whichever your browser can write, which is always PNG and JPG. Set the quality for the lossy ones, and a maximum width if you also want it smaller on screen.
Every card shows the new dimensions, the new file size and how much it changed. Save one file, or take the whole batch as a ZIP.
The choice is nearly always decided by two things: whether the picture is a photograph, and whether any of it has to be see-through. Then by a third, which is what your browser can actually write. That last one is covered under the table.
| Format | Transparency | Lossy | Convert to it when |
|---|---|---|---|
| PNG | Yes | No | Screenshots, logos, charts, anything with flat colour or hard edges. Nothing is thrown away. |
| JPG | No | Yes | Photographs, and anywhere something old has to open it. Every device made since 1995 can. |
| WebP | Yes | Yes | The web, in 2026. Roughly 25 to 35% smaller than the same JPG, and it keeps transparency too. |
| AVIF | Yes | Yes | Smaller again than WebP on photographs. Every browser shows one and almost none can write one, so this is mostly a format you convert away from. |
The one that surprises people is PNG to JPG making the file bigger. That happens on screenshots and diagrams, where PNG's compression is close to perfect and JPG has to work hard to fake the same hard edges. Every card shows the size change before you save anything, so you never have to guess which way it went. There is more on that particular pair on the PNG to JPG page.
Every current browser displays all four of these, so opening a WebP or an AVIF here works everywhere. Writing them is a separate feature, shipped separately, and the split today is awkward:
| Browser | Can save as | Cannot save as |
|---|---|---|
| Chrome, Edge | PNG, JPG, WebP | AVIF |
| Safari | PNG, JPG | WebP, AVIF |
Measured on Chrome 151 and Safari 26, in August 2026. So the format buttons are tested when the page opens and the ones your browser cannot write are taken off the bar, with a line underneath saying which and why. Asked for a format it does not have, a browser hands back a PNG carrying the wrong file extension rather than an error, and a mislabelled file is worse than a missing button.
The useful consequence runs the other way. Because reading is universal, WebP to PNG, WebP to JPG and AVIF to JPG all work in every browser, and those are the conversions most people actually arrive here needing. It is only saving into the newer formats that depends on which browser you opened this in.
A format change is a decode and an encode. The file is turned into raw pixels, and those pixels are written back out under the new format's rules. That has three consequences worth knowing about, and none of them are peculiar to this tool.
Metadata does not survive. EXIF, the camera and lens, the timestamp, the GPS coordinates: all of it is attached to the file rather than to the picture, and none of it is carried across. For anything going on the public web, losing the GPS tag is the point.
Rotation is baked in. A phone photo is often stored sideways with a tag saying which way up it goes. Since the tag cannot be written back out, the rotation is applied to the pixels here instead, so the saved file is the right way up on its own.
Lossy is one way. Converting a JPG to PNG does not restore what the JPG threw away. It only stops any more being thrown away from here on. If you have the original, convert from that rather than from a copy that has already been through a lossy encoder.
The number on the slider is a setting handed to the encoder, not a proportion of the picture that survives. 85 does not mean 85% of the original. It means a particular trade the encoder makes between file size and detail, and the same number produces different results in JPG, WebP and AVIF, because all three are doing different maths.
For photographs, 80 to 85 is where most people stop being able to see the difference. Below 70 the flat areas start to band and the edges pick up a halo. Above 92 the file grows fast and the picture barely improves. Every file here is re-encoded from the original you dropped in, never from the previous result, so you can move the slider as many times as you like without stacking one lossy pass on top of another.
Max width scales the picture down before it is encoded, keeping the aspect ratio, and never scales anything up. It is here because the two jobs so often arrive together: a 4000px phone photo going onto a web page needs both a smaller format and fewer pixels, and doing it in two passes would encode the file twice for no reason. A file already narrower than the limit is left at its own size.
It reads anything your browser can display: PNG, JPG, WebP, AVIF, GIF, BMP, ICO and SVG. It writes PNG, JPG, WebP and AVIF, but only where your browser can. Reading a format and writing it are separate features, and browsers ship them separately. Chrome writes PNG, JPG and WebP but not AVIF. Safari writes only PNG and JPG: it displays WebP and AVIF perfectly and can encode neither. So the buttons are tested when the page opens, the ones this browser cannot write are taken off, and a line under them says which and why.
Because outside Safari, no browser can decode HEIC. It is an Apple format built on the HEVC video codec, and the licensing around that codec is why Chrome and Firefox never shipped a decoder for it. There is no server here to hand the file to instead, so on Chrome or Firefox this tool genuinely cannot open one, and it says so on the card rather than failing quietly. On a Mac or an iPhone, Safari opens them here fine. The guide below has the fix for every other case.
Yes, all of it, and that is not an option you can turn off. The conversion decodes the picture to pixels and encodes those pixels again, and nothing that was not a pixel survives the trip. So the camera model, the timestamp, the lens settings and the GPS coordinates are all gone from the file you save. For a photo going onto the public internet that is usually the outcome you wanted. If you need the metadata kept, this is the wrong tool and no browser-only tool will do better.
As many as you can drop on it. There is no file count and no daily cap, because there is no account and no server bill behind either. The real limit is your own machine: each file is decoded to raw pixels to be converted, and a 100-megapixel image is refused rather than left to run the tab out of memory. A batch is converted one file at a time so the page stays responsive while it works.
Not on the file size, on the pixel count. A converted image has to exist as raw pixels in memory at some point, and raw pixels cost four bytes each whatever the file on disk weighed. So a 12 MB JPG is nothing, while a 100-megapixel scan is 400 MB of memory before anything is encoded. Anything above 100 megapixels is refused with a message rather than left to crash the tab. A 200 MB video-still PNG will open fine; a gigapixel panorama will not.
Because the rotation is applied to the pixels deliberately. A phone usually stores the photo the way the sensor read it and attaches an EXIF tag saying which way up it should be shown. Since re-encoding drops all metadata, that tag cannot be written into the new file, so a naive conversion would hand back a picture lying on its side. The decode here asks for the orientation to be baked in, which means the saved file is upright on its own, even in software that has never read an EXIF tag.