Convert JPG to AVIF
Re-encoding a JPG as AVIF typically halves it, sometimes better, at a quality difference you will not see. The catch is that a JPG has already been through one lossy encoder, so this is compression applied to compression — and the right way to think about that is different from converting a PNG.
Use this without the search next time. Prathom Workbench puts Prathom's tools in your toolbar.
Add to Chrome — freeDrop your JPG file here, or click to browse
Up to 50 MB. Deleted automatically after 30 minutes.
What it does
- Typically 40-60% smaller than the source JPG
- Existing JPEG artifacts are preserved, not repaired
- EXIF orientation applied so photos are not rotated
- Batch conversion for whole folders
How to use JPG to AVIF
- 1
Add the JPGs
Photos from a camera or phone, exports from an editor, or images destined for a website. Several at once is fine.
- 2
Convert
Encoding happens on our server, because no browser can write AVIF. Expect a few seconds per image — AVIF encoding is genuinely slow, far slower than JPEG, and that cost is paid once here rather than by every visitor later.
- 3
Compare before you replace anything
Open the AVIF and the JPG side by side at full size. On a photograph the difference is normally invisible; on an image that was already heavily compressed it can be visible, and that is the case worth catching before you delete originals.
How it works
The JPEG is decoded to raw pixels, its EXIF orientation is applied so the image is physically the right way up, and the result is encoded with libaom using AV1's still-image profile at a quality level tuned for photographs.
The conversion runs on our server rather than in your browser, and that is not a choice. Browsers ship an AV1 decoder but expose no encoder to web pages, so producing AVIF is something no web page can do locally. The reverse direction, AVIF to JPG, is the easier direction for exactly that reason.
Why a JPG source behaves differently from a PNG
This is the part that distinguishes this page from converting a PNG, and it changes what you should expect.
A PNG is lossless. Every pixel in it is exactly what the image is meant to be, so the AVIF encoder is looking at clean data and every bit it spends buys real detail. That is why PNG conversions produce the dramatic tenfold reductions.
A JPG is not. It has already been through a lossy encoder that threw away high-frequency detail and left behind its own characteristic artifacts: blocking along the 8x8 grid, ringing around sharp edges, and color smearing in saturated areas. The AVIF encoder cannot tell those artifacts from real detail. It faithfully preserves them, spending bits on flaws.
The practical consequences are two. First, the reduction is smaller — half rather than a tenth. Second, the source quality matters enormously: a camera JPEG at high quality converts beautifully, and a thumbnail that was already squeezed does not.
Choosing what to convert
Worth converting: camera originals, high-quality exports, large photographs headed for a website, anything above roughly 500 KB.
Not worth converting: small thumbnails, images already saved at low quality, anything under about 30 KB where AVIF's container overhead eats the saving, and graphics with hard edges and flat color — those were never good JPEGs in the first place and should be PNG or WebP.
Keep the originals
Because both formats are lossy, the AVIF is strictly downstream of the JPG: converting back later returns the file to a JPEG container without returning anything discarded along the way. Treat the AVIF as a delivery format for the web and keep the JPG as the copy you edit, archive, and email.
Examples
A camera photograph
Around 60 percent smaller with no visible difference at full size. Camera JPEGs are saved at a high quality setting, so there is plenty of headroom for a better encoder to work with — this is AVIF at its most useful.
An already-compressed web image
Barely smaller, and marginally worse. The JPEG's blocking artifacts are real detail as far as the AVIF encoder is concerned, so it spends bits preserving them and then adds its own smoothing on top. Heavily compressed images are the case where converting is not worth doing.
Frequently asked questions
Am I losing quality twice by doing this?
Yes, and it is worth being precise about it. The JPEG discarded detail when it was created and that detail is gone permanently — this conversion cannot recover it and does not try. AVIF then applies its own lossy pass on top. On a high-quality source the second pass is invisible; on a low-quality one it compounds visibly, which is what the second example shows.
Why is this slower than your other image conversions?
AVIF encoding is computationally expensive — it uses the intra-frame coding from the AV1 video codec, which searches many possible ways to predict each block before choosing one. That search is where the compression gain comes from. Decoding is fast, so the visitor viewing your image later pays nothing for it.
Will the AVIF display everywhere the JPG did?
On the web, effectively yes: every current browser supports it. Off the web, no. Email clients frequently fail, and a lot of desktop software still cannot open one. AVIF is a format for serving images to browsers, not for sending files to people — for that, keep the JPG.
Does it keep EXIF and rotation?
Orientation is applied to the pixels so the image is the right way up wherever it is opened, rather than relying on a tag that many viewers ignore. Other EXIF fields are not carried across. If capture dates or camera settings matter to you, keep the JPG originals — this output is meant for delivery, not archiving.
Further reading
- Compressed, Base64 Cost Nothing on a JPEG and 17% on JSONBase64 costs a third, and almost everything it travels over is compressed, so the real question is what survives the compressor. The answer is not one number: on already-compressed data the overhead vanishes, and on compressible data a sixth of it stays.
- Hex Is Twice the Size of Your Data, Base64 Is a Third MoreHex and base64 solve the same problem — get binary through a channel that only carries text — and one of them costs six times as much as the other. Hex still turns up constantly, and usually for a reason that has nothing to do with size.
- Mono at 16 kHz Was a Fifth of Stereo, and at a Fixed Bitrate Nothing ChangedMaking a recording mono is the standard advice for shrinking speech audio, and whether it works depends entirely on a setting most people never touch. Set one way it saves eighty per cent; set the other way it saves nothing at all and quietly improves the quality instead.