Initializing... drag & drop files here
Supports: JPG, JPEG, JFIF
AVIF (AV1 Image File Format) is the AOMedia still-image format derived from the AV1 video codec; the 1.0.0 specification was published in February 2019. At equivalent perceptual quality, AVIF photos typically land 40–60% smaller than JPEG and routinely beat WebP by 10–20%. Unlike JPEG, AVIF supports an alpha channel, 10- and 12-bit color, wide-gamut color spaces (Rec. 2020, P3), HDR, and lossless compression — so a single output format can replace JPEG for photos and PNG for graphics with transparency.
<picture> with a JPEG fallback for the small share of legacy browsers..avif and generates intermediate sizes automatically.| Property | JPG / JPEG | AVIF |
|---|---|---|
| Standardized | 1992 (ISO/IEC 10918-1) | February 2019 (AOMedia 1.0.0) |
| Compression | Lossy (DCT) | Lossy and lossless (AV1 intra) |
| Typical photo size at matched quality | 1× baseline | ~0.5× (40–60% smaller) |
| Color depth | 8-bit per channel | 8 / 10 / 12-bit |
| Color gamut | sRGB in practice | sRGB, Display P3, Rec. 2020 |
| Transparency (alpha) | No | Yes |
| HDR | No | Yes (PQ and HLG) |
| Animation | No | Yes (image sequence) |
| Browser support (caniuse, 2026) | ~100% | 94.3% global |
| Encode CPU cost | Very low | Higher (AV1 intra is heavier) |
| Decode CPU cost | Very low | Moderate; hardware decode improving |
| Preset | Target use | Typical size vs source JPG |
|---|---|---|
| Highest | Archival masters, print-bound exports | 70–90% |
| Very High (default) | Hero images, photography portfolios | 45–60% |
| High | Standard product and editorial photos | 30–45% |
| Medium | Thumbnails, blog body images, lazy-loaded grids | 20–30% |
| Low / Very Low / Lowest | Placeholders, low-priority background art | 10–20% |
Quality controls how aggressively pixel data is encoded; resolution controls pixel dimensions. Reducing both together produces the smallest deliverables — for example, a 4000×3000 JPEG at "Very High" plus a 50% Resolution Percentage often yields an AVIF under 100 KB with no perceptible loss when displayed at typical web widths.
For typical photographic content the reduction is 40–60% versus the source JPEG at matched perceptual quality. Smooth content (skies, skin, blurred backgrounds) compresses best because AV1's intra prediction excels on low-frequency regions; busy textures (foliage, fabric, fine text screenshots) see smaller gains, sometimes 20–30%. Re-encoding an already-low-quality JPEG yields less savings than starting from a high-quality master.
No. JPEG is lossy, so detail discarded during the original encode is gone — AVIF cannot reconstruct it. What AVIF does prevent is additional generational loss: at "Very High" preset the AVIF output is visually indistinguishable from the input JPEG even under pixel-peeping, so you keep what you have without paying again for blocking artifacts. Always start from the highest-quality JPEG master available.
Per caniuse, AVIF is supported in Chrome 85+, Edge 121+, Firefox 93+, Safari 16.4+ (desktop) / 16.0+ (iOS), Opera 71+, and Samsung Internet 14+ — about 94.3% global usage. The ~5–6% gap is mostly older iOS, locked-down enterprise Windows builds, and in-app browsers. The standard pattern is <picture><source type="image/avif" srcset="...avif"><img src="...jpg"></picture> so AVIF-capable clients get the small file and the rest fall through to JPEG.
Yes, since WordPress 6.5 (released April 2, 2024). The Media Library accepts .avif uploads and generates intermediate sizes automatically, provided your hosting environment has an image library compiled with AVIF support — typically libgd ≥ 2.3.3 or Imagick built against libavif. Check Tools → Site Health → Info → Media Handling and look for AVIF in the supported MIME types list. If it's missing, ask your host to enable it or use a plugin that runs conversion server-side.
AVIF uses AV1's intra-frame coding, which evaluates many more block partitions, prediction modes, and transform sizes than JPEG's fixed 8×8 DCT. That extra search produces better compression but costs more CPU — on the order of 10–50× slower than libjpeg-turbo for a single image. Decoding is much cheaper, and most 2024+ devices include hardware AV1 decode. For batch jobs the encode cost is a one-time export step; users only pay decode cost on view.
Yes — AVIF supports a full alpha channel up to 12-bit. JPEG does not, so a JPEG → AVIF conversion has no alpha to carry through; you'll get an opaque image. If you need transparency for logos, icons, or product cutouts, start from PNG instead — try PNG to AVIF or convert through AVIF to JPG for the round trip back to a non-transparent format.
AVIF compresses better than WebP at the same perceptual quality — typically 10–20% smaller for photos and noticeably better for low-bitrate targets. WebP has slightly broader support (it works in iOS 14+ vs AVIF needing 16.0+) and encodes faster. The pragmatic answer for new content in 2026: serve AVIF first, list WebP next as a fallback for the small remaining gap, and JPEG last as the universal floor — <picture> will pick the first that the browser advertises support for.
Conversion runs entirely in your browser using WebAssembly; image bytes are not uploaded to xconvert's servers. There's no sign-up, no watermark, and no daily limit. Files leave only your machine if you choose to share or upload the resulting AVIF yourself.
JPEG re-compression at lower quality discards more DCT coefficients, which produces visible 8×8 blocking and ringing around edges. AVIF re-encodes from the (already-decoded) JPEG pixels using a fundamentally better algorithm — variable block sizes from 4×4 up to 64×64, more prediction modes, and better entropy coding — so for the same target byte budget AVIF looks substantially cleaner. If size is the goal and modern browsers are acceptable, AVIF wins; if you must keep JPEG, see Compress JPG for an in-format size reduction.