Convert PNG to AVIF — For Transparent, High-Resolution Asset Libraries
Your product cut-outs are 20 MB each. Same images as AVIF ship under a megabyte with the alpha intact. Drop the folder — every core encodes at once, nothing uploads.
For asset libraries that were PNG because of alpha
Drop your transparent-PNG folder. Alpha carries across intact, or gets skipped if the file turns out opaque. Every image encodes across every core on your machine — and nothing ever leaves the tab.
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.
Why AVIF — specifically — is the right target here
AVIF wasn't designed as a general PNG replacement. It was designed as AV1's still-image sibling, and its alpha handling is the part nobody else got right. That's exactly why it fits a transparent-asset pipeline better than either WebP or modern PNG tooling.
Your product cut-outs are hogging a hard drive
A 12 MP cut-out of a product on transparent backing. A hero overlay with a feathered edge. A marketing visual with a drop shadow. They're PNGs because you needed the alpha — and they land at 15 to 40 MB apiece because nothing else was willing to carry it. AVIF finally is. Same cut-out, under a megabyte, alpha intact. This page is about moving that specific asset library across.
Alpha, actually done right
The alpha signal on a cut-out is almost all flat 0 and 255 with a thin anti-aliased seam. AVIF's intra coder flattens that into almost nothing. Color planes ride one path, alpha rides another, neither one compromises the other. And if a 'transparent' PNG turns out to be fully opaque — a surprising number of them are — the encoder notices and skips the alpha plane entirely.
The encode finishes before you refill the coffee
Most browser AVIF tools run single-threaded and take half a minute per photo. This one splits every image into tiles and encodes them across every core you have. A 12 MP cut-out on an 8-core laptop finishes in a few seconds, not a full minute. Queue a hundred, they go in parallel, metered against your RAM so the tab stays responsive the whole time.
Under the hood
The alpha-aware encoder is libavif on top of libaom, compiled to WebAssembly with pthreads and tile-parallel encoding wired up. Tiles are derived from thread count with a 512 px minimum-tile floor. The memory-aware scheduler reserves px × 7 + 80 MB of wasm heap per AVIF encode and gates dispatch at half the device's RAM so nothing fights for headroom. Cross-origin isolation is already configured on this domain, which is why parallel encode works at all.
Where a 12 MP transparent PNG actually ends up
| Criterion | PNG | WebP |
|---|---|---|
| Cut-out product shot (alpha, 12 MP) | ~20–40 MB | typically under a megabyte |
| Flat UI screenshot / logo | baseline | WebP lossless usually wins — use that page |
| Alpha plane handling | 8-bit, always present | 8-bit, skipped if fully opaque |
| Size vs WebP | — | ~20–40% smaller than WebP |
| Encode wall-clock | n/a | 5–20× slower than WebP per image |
| Parallelism on a single image | n/a | Tile-parallel across every core |
| Browser support | universal | Chrome 85+, Firefox 93+, Safari 16.4+ |
From a transparent-PNG folder to an AVIF ZIP
Per-image alpha inspection, parallel encode across every core, metadata re-embedded, delivered as a ZIP.
- 1
Drop the transparent-PNG folder
Product cut-outs, overlays, marketing visuals with alpha — drag the folder onto the drop zone. A 48 MP source hidden in the batch won't blow the heap before you've even scrolled.
- 2
Alpha is inspected, not assumed
Each file is checked for actual transparency. If none exists, the alpha plane is skipped entirely and the output shrinks a little more. Otherwise the alpha rides alongside the color planes, intact.
- 3
Per-image quality search
Every image gets its own encode setting — a short binary search for the point where the eye stops spotting artifacts on that specific photo. Soft photographic content hits it faster than sharp graphic content, so no two encodes use the same quantiser.
- 4
Collect the ZIP
Output lands as a ZIP mirroring your input folder layout. The results view reports per-file byte savings and whether the alpha plane was encoded or skipped — useful when triaging why one file shrunk more than its neighbour.
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)
PNG to AVIF — designer and engineer questions
Is AVIF really worth the wait versus staying on WebP?
For high-resolution photographic PNGs with transparency, yes — 20–40% smaller than WebP at matched perceptual quality is common. For flat UI graphics, logos and icon sets it often isn't; WebP lossless usually wins on those, and the PNG-to-WebP page is the better target. This tool is aimed at the first case.
What happens when my PNG turns out to be opaque after all?
The encoder notices and drops the alpha plane rather than writing a flat 255 channel. Trims a few percent off the output and makes the decode on the client slightly cheaper. You'll see 'opaque' in the per-file report when it happens — a small surprise that's almost always welcome.
How does a 48 MP PNG not crash the tab?
The memory-aware scheduler estimates heap footprint at roughly px × 7 + 80 MB for AVIF, compares that against half the device's RAM (500 MB floor), and holds encodes back until they fit. Large images wait for headroom instead of fighting each other for it.
Will the AVIF output keep my Display P3 or Adobe RGB profile?
Yes. The ICC profile is lifted during decode and written directly into the AVIF's color-information box. EXIF and XMP ride the same path.
Why does a single large AVIF encode use every core?
Because most browser AVIF tools don't. They run single-threaded or cap at four threads. This one splits every image into tiles and farms them across every core you have. A lone encode on an 8-core machine uses all 8 cores; two concurrent encodes split 4/4. That adaptive split is why the wall-clock here is actually competitive despite AV1's reputation.
My output file is bigger than the input PNG. When does that happen?
Very small images can invert — the AVIF container overhead outweighs the compression win on simple graphics under a megabyte. The converter flags these in the results view; for tiny logos and icons, PNG → WebP lossless is almost always the right move instead.
Can I feed an asset pipeline with this?
As a designer-hands-on tool today — drop, wait, download. There's no public API or command-line export yet. Every encode happens inside the tab, which means nothing is uploaded and nothing leaves the device; an automated pipeline would need a different deployment anyway.
Is APNG animation converted to animated AVIF?
Not yet. The decoder reads the first frame of an APNG; anything after that is ignored. Animated asset flows should go through a video pipeline for now — MP4 or AV1-in-MP4 is almost always a better target than an animated still-image format.
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. 🎯