Make your AVIF files smaller without changing format. Blinkimg re-encodes AVIF to cut file size while keeping the sharp quality the format is known for. Free, and in your browser.
Drop images or browse
JPEG · PNG · WEBP · AVIF · HEIC · max 30 MB
Auto tunes each image.
A hard cap for “under 50 KB” portals.
Empty side keeps the ratio. Never enlarges.
AVIF · 171 KB
AVIF · 68 KBA quality-scale mismatch, almost always. The question brings most people here, and it has a measurable answer. AVIF's quality numbers run lower than JPEG's for the same appearance. On our reference photo, AVIF at quality 80 measured 164.1 KB while quality 60 measured 114.7 KB, visually indistinguishable. People encode AVIF at 85 "to be safe", produce a file bigger than their JPEG, and conclude the format is broken. It isn't; the dial is different. Two rarer causes: an encoder set to its fastest effort (the documented fast-vs-thorough swing is 20–40% at identical quality), and re-encoding a source that was already heavily compressed.
| Encode | Size | Rule of thumb |
|---|---|---|
| AVIF quality 60 | 114.7 KB | The AVIF sweet spot |
| JPEG quality 80 | 82.1 KB | ≈ same appearance |
| WebP quality 90 | 188.3 KB | ≈ same appearance |
| AVIF quality 80 | 164.1 KB | Bytes without benefit |
Same 188.3 KB source photograph, encoded at the settings that land near-equal visual quality.
How these numbers are measured: every byte count on this page is the size of the actual encoded file our engine produced from the named source image. Those are the same bytes you would download, not an estimate or a best case. Rerun any of them yourself: drop your own file into the tool above and the meter reports your real result.
Two honest outcomes, both automated. Many AVIFs have headroom because a CMS or an exporter encoded them at conservative quality. We measured a real example: the 175.3 KB reference re-compressed to 70.1 KB on Auto. But when a file is already at the efficient frontier, re-encoding would grow it. In that case our never-larger guard hands back your original untouched and says so, instead of shipping a bigger file labelled "compressed". If the result says your file was already optimal, the next lever is dimensions, not quality: resize it.
The specification supports full alpha transparency, animation, 10/12-bit depth, HDR and wide colour gamut. What our compressor does with each, stated plainly: we preserve alpha (check edges against the checkerboard in the compare slider); we decline animated AVIF rather than silently flatten it to frame one; we output 8-bit sRGB for maximum compatibility, so extreme HDR highlights tone-map the same way they would in any JPEG or WebP workflow. If HDR delivery matters to you, keep the original and serve it to the audiences that can render it.
Short answers specific to this page. The tool above settles most of them in a second.
Every route in and out runs on the same engine and the same rules. Each card is its own page.
Roughly half the bytes of WebP on most photos. Slower to encode, worth it at scale.
Transparency survives and size collapses. Check thin type and 1px strokes in the preview first.
One more step down the size curve for pages already on modern formats. Keep WebP as the fallback.
When something rejects the upload, this is the format it wants. Photos only, no transparency.
Keeps alpha and gives every editor something to open. Expect a large file. That's the trade.
Broader support, still modern compression. The middle path when AVIF is one step too far.
Drop it in above. The meter reports the exact saving before you download anything.