convert to
resize
✓ EXIF, GPS and all other metadata are removed from the output.
Drop images here
or click to browse — PNG, JPEG, WebP, GIF, HEIC, AVIF, SVG — you can also paste images (Ctrl+V) anywhere on this page
Re-encode a JPG as AVIF locally — and find out why the same quality number on a newer codec does not automatically save bytes.
Your files never leave your browser — all processing is local.
✓ EXIF, GPS and all other metadata are removed from the output.
Drop images here
or click to browse — PNG, JPEG, WebP, GIF, HEIC, AVIF, SVG — you can also paste images (Ctrl+V) anywhere on this page
Structurally the source has nothing to give up: no alpha channel, no frames, nothing deeper than 8 bits. What it does have is a history, and that history is the real subject of this route. The first encoder already split the picture into 8 × 8 blocks, quantized each one, and stored color at half resolution in both directions; the block boundaries, the ringing haloes around high-contrast edges and the smeared color are now part of the decoded pixels. The AV1 encoder that receives them has no way to tell a block edge from an eave line or a quantization halo from a genuine highlight, so it faithfully reproduces the previous encoder's mistakes and spends bits doing it. Nothing it does repairs the original loss; it only adds a second layer on top.
That second layer is much gentler in character than the first, which is the one genuine advantage of the pair. AV1's intra prediction works on variable block sizes with directional predictors, so where it does fall short it tends to soften texture rather than produce the blockiness and ringing the source is full of. But it also cannot use the parts of the format that would have mattered: the encoder is fed an 8-bit RGBA buffer read back from a canvas, so 10-bit output and 4:4:4 chroma are off the table, and the half-resolution color the source threw away stays thrown away.
Everything outside the pixels is dropped, because the file is rebuilt rather than repackaged. Capture date, camera and lens fields, exposure settings, GPS coordinates and the embedded ICC profile are all absent from the output. Orientation is the one field with an effect that outlives it: the decoder is asked for the image as it should be displayed, so a photo tagged sideways is rotated in the pixel data before encoding. It comes out upright, and it can never be rotated again by editing a tag.
This is the pair that contradicts the marketing. On 2026-09-12 the script encoded a 1280 × 854 source to JPG at quality 85 — 351,967 bytes — and then to AVIF at quality 85, speed 8: 480,106 bytes. The output was about 36% larger than the input. Both numbers say 85, and that is exactly the trap: the two scales belong to different encoders and describe different operating points, and libaom's 85 aims considerably higher than libjpeg's. On top of that the AVIF was asked to reproduce an image already full of artifacts, which is expensive. The familiar claim that AVIF halves a JPG is measured by encoding both formats from an uncompressed master at matched visual quality. It is not a claim about transcoding, and this measurement is what transcoding actually looks like.
Do not bulk-transcode a photo archive on the strength of the headline figure — on this evidence you would add a lossy generation to every file, strip the dates and locations the library is sorted by, and quite possibly end up with more bytes than you started with. If the originals still exist, export from those; that is the comparison the 50% figure comes from. Do not convert files headed for print, email, an upload form with a fixed extension list, or anyone who needs the EXIF for provenance. Do not convert a JPG that was already squeezed hard, because you would be spending AV1 bits on preserving its damage. Converting one large image for a page whose markup you control, with the quality slider pulled down and the size readout checked, is a perfectly sound reason.
Conversion happens entirely in your browser — no upload, no queue, no watermark. Drop in as many files as you like and download them individually or as a zip.
Because the two encoders were both set to 85 on scales that are not comparable, and the newer one was asked to reproduce an image already full of compression artifacts. In the measured sample 351,967 bytes became 480,106. Lower the quality slider and watch the size readout rather than trusting the number.
No. Each encoder maps that number onto its own quantizer, and libaom's 85 targets a noticeably higher fidelity than libjpeg's. Comparing formats at the same slider position compares two different targets, which is why the size can move in the direction you did not expect.
Usually not. You pay an extra lossy generation and lose the metadata on every file, and the measured sample grew rather than shrank. The large savings people quote come from encoding an original master, so convert selected images from their sources instead of reprocessing the archive in place.
No. Conversion happens inside your browser using the canvas API and a Web Worker — files never leave your device. There is no upload step, no queue and no file size limit beyond your machine's memory.
No — and that's a feature. Re-encoding through the canvas strips all metadata: GPS location, camera model, timestamps and color profiles. The output contains pixels only, which is usually what you want before sharing an image publicly.
Yes. Drop or paste any number of files; each is converted in the background with its own progress and download button, and you can grab everything at once as a .zip archive.
It depends on the target. The converter always decodes to raw pixels and re-encodes, whichever formats are involved, which is also how metadata gets stripped. For lossless targets (PNG, and GIF within its 256-color limit) the pixels stay identical to what was decoded; for JPEG, WebP and AVIF the quality slider controls the trade-off, and converting a file that is already lossy adds one more generation of loss.