Convert JPG to AVIF — Archival Compression, Encoded Locally
Half the weight of the source JPG. About 40% under WebP. Every core on your machine, encoding at once. Drop a folder, walk away, come back to a far smaller archive.
Drop photos in — leave the tab running
The smallest still-image format mainstream browsers render today, encoded on every core you have. Great for archives and CDN budgets. Not ideal when you need the batch done in five minutes — use the WebP page for that.
Supported input formats
- ✓ JPG / JPEG — Photos, portraits, web content
- ✓ PNG — Screenshots, icons, transparent images
- ✓ HEIC / HEIF — iPhone photos, Apple formats
- ✓ TIFF — Scans, prints, high-resolution archives
- ✓ GIF — Animations and static GIFs
- ✓ BMP, PSD & more — Anything ImageMagick can decode
How the conversion works
- 1. DropDrag files or a whole folder into the box below. Folder structure is preserved in the output ZIP.
- 2. AnalyzeEach image is analyzed for entropy and content type. The engine picks per-image quality settings targeting PSNR ≥ 44.5 and SSIM ≥ 0.95.
- 3. EncodeConversion runs on all of your CPU cores in parallel via Web Workers. EXIF, ICC color profiles and geolocation are copied onto the WebP or AVIF output.
- 4. DownloadWhen the batch is done, a ZIP containing every converted file downloads automatically. No re-upload, no waiting on a server.
AVIF in practice — where it pays off, where it doesn't
AVIF buys you maximum compression at the cost of encode time. Here's how that tradeoff plays out when you run it locally, and where the encoder picks its fights.
For people who count bytes
Your CDN bill keeps climbing. Your phone library ate iCloud. Your publishing stack compounds every kilobyte across a million pageviews. AVIF is the most compression you can get out of a photograph today without resampling or losing quality. At the same perceptual bar: roughly half the source JPG, about 40% under WebP. The only tax is time.
Every core, every photo
Most browser AVIF tools run the encoder single-threaded, or capped at four threads. We split every image into tiles and farm them across every core you have. A 24 MP photo on an 8-core laptop saturates the whole chip instead of pegging one core and cooking the fan. You'll feel it on batch work — that's where the hours come back.
Metadata lives inside the container, not beside it
EXIF, XMP and ICC land straight into the AVIF file. Finder previews find them. Lightroom finds them. exiftool finds them. No sidecars, no lost capture dates, no broken color calibration five years from now when someone opens the archive on a different machine.
Budget the time, keep the bytes
AVIF encode is 5–20× slower than WebP per photo — AV1 simply does more work per block. A 1000-photo archival run is the difference between a coffee break and leaving the tab open over dinner. The flip side: the 12 GB batch lands closer to 6 GB. If throughput matters more than final size, the WebP page is the right door.
JPG vs AVIF — the tradeoff at a glance
| Criterion | JPG / JPEG | WebP |
|---|---|---|
| Typical file size at matched quality | 100% | ~50% (≈half the bytes) |
| Size vs WebP on the same photo | — | ~40% smaller than WebP |
| Encode time per photo | — | 5–20× slower than WebP |
| Color depth | 8-bit only | 8 / 10 / 12-bit, wide-gamut |
| Browser support (2026) | Universal | Chrome 85+, Firefox 93+, Safari 16.4+ |
| Parallelism on a single image | — | Tile-parallel across every core |
From JPG archive to AVIF archive
Designed for long-running batches. Start the encode, step away — every core stays busy for the duration.
- 1
Load the archive you want to shrink
Drop a photo, a selection, or the whole folder. Folder structure carries into the output ZIP — useful when you're moving a multi-year library and want your 2019 trip kept together.
- 2
The tile-parallel encode kicks in
Each image gets split into tiles and encoded across your cores at once. A lone encode takes every core; two concurrent encodes split them 50/50. Big files don't elbow out small ones — the scheduler reserves heap headroom before dispatching.
- 3
Quality chosen per image, not per batch
Every JPG gets its own quality search — the encoder looks for the setting that's transparent to the eye on that specific photo. A flat product shot and a noisy low-light portrait want different settings, and they get them.
- 4
Walk away, come back to a ZIP
When the last image finishes, the browser hands you a ZIP of .avif files with matching names. The summary reports total bytes saved — the number that actually moves your CDN bill.
AVIF Results
AVIF matches WebP quality (SSIM Δ < 0.005) while shipping ~45% smaller files on the same Excellent preset.
Typical AVIF savings
Measured on 24 diverse photos at matched perceived quality (SSIM ≥ 0.95)
JPG to AVIF — questions about the tradeoffs
Why does AVIF encode faster here than on other browser tools?
Because most browser AVIF tools run the encoder single-threaded, or capped at four threads. We split every photo into tiles and farm them across every core you have. On a large image that's roughly a 6× speedup over the default path. You'll feel it on batch work.
Why is AVIF so much slower than WebP in the first place?
AV1 is an order of magnitude more sophisticated than the older codecs WebP is built on — more prediction modes, more partition options, more rate-distortion decisions per block. That extra search is exactly what buys you the ~40% size advantage over WebP. It is not free. Per photo you should budget 5–20× the time of a WebP encode. If you need it done in five minutes, the JPG-to-WebP page is the right door.
Is AVIF a good choice for archiving a phone photo library?
This is one of its best use cases. Cutting a multi-year iPhone or Pixel library in half is a real number when you're paying for cloud storage, EXIF and GPS survive the round trip, and modern viewers on iOS 16.4+, macOS 13+, Windows 11 and Android 12+ render AVIF natively. Kick off a big batch before bed and it'll be done by morning.
Will AVIF fit my CDN pipeline?
Most modern image CDNs — Cloudflare Images, Bunny, Fastly IO, imgix — serve AVIF to supporting browsers with automatic fallback. For static hosting, use <picture> with an AVIF <source> and a JPG fallback for the ~5% of traffic still on older clients. Filenames match the source, so swapping references in templates is mechanical.
Do AVIF files keep the color accuracy of the original?
Yes — often better than WebP, actually. The ICC profile is embedded directly, and AVIF natively supports 10 and 12-bit depth and wide-gamut color spaces. The quality search targets the point where the human eye stops spotting compression artifacts on natural images.
What about EXIF, XMP and GPS metadata?
Read from the source JPG, written into the AVIF's native metadata boxes. Lightroom, exiftool, Finder, Adobe Bridge and Windows Photos all find them. No sidecar, no orphaned GPS coordinates, no mystery about when a photo was taken.
How large a batch can I actually run?
No hard cap — the practical ceiling is RAM and patience. The scheduler reserves heap per in-flight encode and recycles each worker every 32 jobs to keep memory stable on long runs. A low-end laptop comfortably handles 500-image runs; a workstation chews through several thousand in one sitting.
What actually gets downloaded to make this work?
A single image-processing engine, under 5 MB. It caches after first load. Cross-origin isolation is already configured on this domain, which is why AVIF encode parallelises across every core instead of stalling on one or two.
Why Choose SciZone?
We're not just another optimizer. We engineered a fundamentally better solution.
| Feature | SciZone (You're here) | Other Optimizers |
|---|---|---|
| CPU Utilization
How processing power is used
| True Multi-Threading Intelligently uses all CPU cores without overloading your system | Single-Threaded Uses only one CPU core, wastes available power |
| AVIF Encode Speed
How fast AVIF actually runs in the browser
| Tile-Parallel Encoding Each AVIF image is split into tiles encoded across every core — ~6× faster than single-tile libaom on large photos | Single-Tile Default libaom's internal threading caps around 4 threads per encode, regardless of how many cores you have |
| Quality Settings
How compression is optimized
| Unique Per Image Algorithm analyzes each photo and picks optimal settings | One-Size-Fits-All Same settings for every photo, inconsistent quality |
|
Metadata & Color Profiles
Preservation of image data
| Fully Preserved EXIF, color profiles, geolocation. Everything stays intact | Often Stripped Color profiles lost, metadata incomplete |
|
Quality-Size Balance
Optimization results | Perfect Balance Maximum compression with imperceptible quality loss | Inconsistent Either too large or noticeable quality loss |
The Bottom Line
Every photo is unique. Our intelligent algorithm understands this and analyzes each image individually to find the perfect balance between file size and quality. We utilize your computer's full power without overloading it, preserving every detail of your metadata and color profiles. Your files are smaller, faster, and absolutely perfect. 🎯