Drop a picture in any common format and get a JPG back. The three things JPEG makes you decide — how much quality to spend, what colour replaces transparency, and what happens to the metadata — are controls here rather than guesses.
Why a JPG, and when not to
JPEG was designed in 1992 for photographs, and it is still the best thing there is at that job. It stores continuous tone — skin, sky, foliage, anything where one colour slides into the next — and it discards the parts of that detail the eye is least likely to miss. A photograph at quality 82 is usually a fifth of the size of the same picture stored losslessly, and looks the same at any sensible viewing distance. It is also the most widely readable picture format that exists. Every upload form, every printer, every twenty-year-old machine and every piece of software that has ever touched a photograph will open one.
It is poor at almost everything else. Flat colour, hard edges, text, screenshots, diagrams, logos, pixel art: JPEG works in eight-by-eight blocks, and a hard black line on a white ground gives it nothing to average, so it produces a grey shimmer around the line instead. It has no transparency at all. It is eight bits per channel, so a 16-bit scan loses precision that a print shop may care about. And every save is another generation of loss — a JPEG opened, edited and saved four times has been through the encoder four times, and the damage accumulates.
The case where converting is a mistake: the file is already a JPEG and nothing about it needs to change. Re-encoding it here at the same quality spends a generation and buys a new modification date. The converter notices, and while the rail is still at its defaults the row offers to hand the original file back untouched instead; move the quality, the matte or a metadata switch and the offer goes, because then the conversion would genuinely change something. The other case is a screenshot of a document, a scanned form or a diagram that is going to be printed or filled in — the destination there is usually a PDF, and JPEG will make the text soft on the way.
Converting a file
- Put the files on the panel at the top of this page. Dragging works, clicking opens a file picker, pressing Enter or Space on the panel does the same, and pasting from the clipboard works anywhere on the page that is not a text field.
- Each row shows what the file actually is, read from its first bytes rather than from its name — a .jpg that is really a HEIC is common enough to plan for, and the row says so.
- Set the quality. By default each photo is measured and gets the lowest quality that keeps its fidelity floor; switch to Fixed for one number (82 to start, with presets). Either way the Quality panel draws this photo's own size curve, and dragging along it picks the number.
- If anything in the picture is transparent, choose the colour that goes behind it. White is the default; black, near-white, any colour from the picker, or a colour sampled from the picture's own edges are all one click away, and the preview shows the result before anything is written.
- If a form has a pixel limit, the Size panel caps the long edge, scales by a percentage, or sets an exact width × height (fill, fit or stretch) — one rule for the whole queue. A KB limit is the Target mode in Quality. Result, Split, Original and Loss views show what the JPEG changes before anything is saved, and every setting can be undone.
- Press Download JPG. Above three files the button writes a single ZIP instead — Download as ZIP does it for any two or more — and each card keeps its own save button for when you only want one of them.
What goes in, and what changes on the way out
Reads: HEIC and HEIF from iPhones and iPads, PNG, WebP including animated, AVIF, TIFF including multi-page and CMYK, BMP, GIF, ICO, and JPEG itself. Everything except HEIC and TIFF goes through the browser’s own decoders — and AVIF, where the browser has no AVIF decoder, goes through a bundled 1.2 MB WebAssembly build of libavif, fetched only then. HEIC goes through a WebAssembly build of libheif, about 1.5 MB, fetched the first time a HEIC is opened and never on a visit where none appears. TIFF goes through a small pure-JavaScript reader on the same terms.
Writes: JPEG. That is the entire output side of this site, and the reason the format control in the rail is fixed and labelled as fixed.
What is lost on the way, named rather than glossed over:
- Transparency. There is no alpha channel in a JPEG. Transparent pixels become the matte colour, and that is a decision rather than a default nobody sees.
- Wide colour. A recent iPhone HEIC is frequently Display P3 and sometimes 10-bit with an HDR gain map. The JPG carries the sRGB conversion: colours outside sRGB clip, and the gain map is discarded.
- CMYK. A CMYK TIFF or JPEG becomes RGB without a colour-managed transform. The colours shift. The row says so before the conversion runs, not after.
- Bit depth. 16 bits per channel becomes 8.
- Movement. An animated GIF or WebP has one frame written; a Live Photo has its still frame written. The motion is not something a JPEG can hold.
Size limits are a control, not a hope: the Target mode in the Quality panel searches for the highest quality that fits under a number of kilobytes, on the real encoder, file by file, and the Form panel sets the KB range, pixel box and DPI an exam portal asks for in one step. Chroma subsampling — the setting that decides how much colour resolution a JPEG keeps, and the reason red text smears on a screenshot saved at 4:2:0 — is a real control too: switch Encoder to Precise and a MozJPEG build, served from this site, writes 4:2:0 or 4:4:4 (or picks per picture), progressive or baseline. The browser’s own encoder stays the default because it needs no download, and it chooses those settings itself.
Format by format, what to expect on the way in
Eight input formats reach the same encoder, and each one arrives carrying a different problem. What follows is the short version of every one of them.
- HEIC and HEIF
- Roughly half the bytes of the JPG you will get back, so the file grows. The decoder is a 1.5 MB download the first time one appears. A recent iPhone file may also be Display P3 and carry a gain map; the JPG keeps the sRGB version of the colours and none of the gain map.
- PNG
- Lossless going in, which means nothing has been thrown away yet and this conversion is the first thing to throw any away. If it is transparent, the matte decides what shows through. If it is a screenshot, a chart or a logo, the honest advice is not to convert it at all — PNG is already the right container for flat colour and hard edges, and JPEG will fray both.
- WebP and AVIF
- Both are usually lossy already, so the JPG is a second generation and will be larger than the file it came from at the same apparent quality. People convert them anyway, because a fifteen-year-old photo printer has heard of JPEG and has not heard of AVIF. Animated WebP gives up one frame.
- TIFF
- The awkward one. A TIFF may hold several pages, in which case you pick; it may be 16 bits per channel, which becomes 8; and it may be CMYK, which becomes RGB without a colour-managed transform and shifts. Scanner and print output lands here more often than camera output does.
- BMP, GIF and ICO
- Nothing is lost reading any of the three, because there was not much there to lose. A GIF holds at most 256 colours and one frame is taken from an animation. An ICO holds several sizes in one file; the largest is the one converted, the row prints every size that was in there, and picking a smaller one is not a control this converter has.
- JPEG itself
- Allowed, and usually pointless. Re-encoding a JPEG at any quality spends a generation of loss and buys a fresh modification date. So long as the rail has not been moved off its defaults, the row offers the original file back instead, and taking that offer is normally the right answer unless the metadata or the matte is the thing you came to change.