Compress TIFF to AVIF — Turn Terabytes Into Gigabytes
A decade of TIFFs fits on a laptop. A 200 MB 50-megapixel scan lands at 1–3 MB of AVIF, visually indistinguishable. Every core encodes at once, first page of each TIFF, nothing uploads.
In-browser AVIF compression for TIFF archives
Drop a studio archive, a digitization batch, a folder of 50 MP scanner output. CMYK and 16-bit normalise cleanly; every image encodes across every core on your machine. Multi-page TIFFs: only the first page is converted.
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.
When the archive bill outgrows the encode time
Photo studios, digitization projects and raw-pipeline archives all hit the same wall: TIFFs pile up faster than storage budgets. AVIF is the reason the archive can stop growing linearly.
Terabytes, meet a laptop drive
A photo studio's archive of 50-megapixel TIFF masters is measured in terabytes. Re-encoded to AVIF, the same archive routinely collapses to single-digit gigabytes. A 200 MB TIFF of a 50 MP photo lands somewhere between 1 MB and 3 MB — visually indistinguishable from the original at normal viewing distance. When storage cost dominates a project, no other still-image target pays off this hard.
Every core, every image
A 50 MP encode isn't fast. AV1 does much more work per pixel than WebP, and a big scan needs tens of seconds of CPU time. Every image gets split into tiles and encoded across every core on your machine — so that ten seconds is actually ten seconds, not ten seconds times however many cores you left idle. On batch work, that's the difference between finishing overnight and still running Monday morning.
A 1000-image archive is an overnight job
Be honest about the scale. A terabyte of 50 MP TIFFs is roughly 5000 images; that's an overnight-to-multi-day job, not a coffee break. The tab meters memory so you can leave it running without worrying about the browser falling over. Workers recycle periodically to keep the wasm heap healthy. Start it before you leave, come back to a fraction of the storage.
Under the hood
Decode handles LZW, ZIP, uncompressed, JPEG-in-TIFF, CMYK and 16-bit sources — normalising everything to 8-bit sRGB before encode. The AVIF encoder is libaom-powered with tile-parallel encoding, tiles derived from thread count with a 512 px minimum-tile floor so nothing gets shredded into useless fragments. Adaptive per-image quality targets PSNR ≥ 44.5 dB and SSIM ≥ 0.95. Only the first page of each TIFF is converted — for multi-page document scans, use a dedicated splitter upstream.
Archive TIFF vs AVIF compressed copy
| Criterion | TIFF archive | WebP |
|---|---|---|
| Typical 50 MP photo size | 150–300 MB | 1–3 MB |
| Compression ratio | 1× | 50×–100× |
| Encode time per 50 MP image | Instant (lossless) | ~10–30 s all cores |
| Parallelism on a single image | n/a | Tile-parallel across every core |
| Multi-page TIFF input | Stacked in one file | First page only |
| Archive suitability | Master of record | Compressed working copy |
| Why use it | Zero generational loss | Storage cost collapses |
Compress a TIFF archive to AVIF end-to-end
A realistic archivist workflow — drop the batch, meter memory, let the encoder run, come back to a fraction of the storage.
- 1
Point it at the archive batch
Drop a folder of TIFFs — a month of studio output, a decade of scans, a digitization project. No size cap; the scheduler meters dispatch against available memory so the tab stays responsive even on a multi-gigabyte drop.
- 2
Decode and normalise
LZW, ZIP, uncompressed, JPEG-in-TIFF — all handled. CMYK and 16-bit sources get color-managed down to 8-bit sRGB before the pixels reach the AVIF encoder. Embedded ICC profiles ride the whole pipeline.
- 3
Let AV1 run on every core
Each image splits into tiles and encodes across your cores at once. Expect roughly 10–30 seconds per 50 MP photo; quality is picked per image to hit the visually-indistinguishable bar.
- 4
Walk away, come back to a much smaller archive
Output lands at roughly 1–2% of the input archive's byte count. Original TIFFs are untouched — use the AVIFs as the new working archive and keep the masters for anything that ever needs reprocessing.
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)
TIFF to AVIF — questions from archive and digitization projects
How small does a 50 MP TIFF scan actually get in AVIF?
For photographic content at visually-indistinguishable quality, a 200 MB 50-megapixel TIFF lands between 1 MB and 3 MB — roughly 50×–100× smaller. Scans with large flat backgrounds compress harder; fine-grained subjects (textiles, forest canopy, engraved print) compress less. The per-image report shows the final numbers so you can verify each result rather than trusting your eyes.
How long will encoding a terabyte of TIFFs take?
Plan in core-hours, not minutes. AVIF is 5–20× slower than WebP per photo, and a 50 MP image takes tens of seconds even with every core running. A terabyte of 50 MP TIFFs (roughly 5000 images) is an overnight-to-multi-day job on a single laptop. The scheduler meters memory and workers recycle on long runs, so you can leave it.
Is the AVIF output good enough to replace my TIFF masters?
For most photo-studio and photo-scan archives the answer is yes for working copies, no for masters. AVIF at the default quality target is visually indistinguishable from the source at normal viewing distance, but it's lossy and currently 8-bit on this path. If you might reprocess in the future — reprint, re-retouch, re-colorgrade — keep the TIFF master somewhere cold and use AVIF as the active working archive.
Why 8-bit AVIF and not 10- or 12-bit from my 16-bit TIFF?
The current encode path is 8-bit YUV420 because that's where the encoder's still-image tuning lives and where browser decoders are uniformly fast. 16-bit channels are color-managed down to 8-bit before reaching the encoder. 10-bit AVIF output from 16-bit sources is on the roadmap but not wired in yet.
My archive is CMYK proofs from a printer. Are those convertible?
Yes. The CMYK data is read, the embedded ICC profile (FOGRA, GRACoL, SWOP and so on) is applied, and the pixels convert to sRGB before encoding. The resulting AVIF carries an sRGB profile in its color-information box, so any modern browser or viewer renders the intended colors.
What about a 500-page book-scan TIFF?
Only the first page is converted. The pipeline reads the first page of a TIFF and emits a single AVIF — so a book scan gives you the cover page and that's it. For multi-page document conversion, use a dedicated TIFF/PDF splitter to explode the file into per-page TIFFs first, then feed those here.
Will a 500 MB single-image TIFF actually encode, or will the tab crash?
Depends on the resolution more than the file size. The scheduler refuses to dispatch images that won't fit inside half the device's RAM (500 MB floor). On a 16 GB machine a 100-megapixel single scan sits near the 4 GB wasm32 ceiling — it may succeed alone and fail if queued alongside other huge images. Try huge files individually, not in parallel.
Do I need to trust an upload server with unreleased or sensitive material?
No. Everything runs in the browser tab. The image engine is under 5 MB, downloaded once and cached. Your archive never moves off the machine — open DevTools → Network during a run and you'll see the module load once and nothing else leave.
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. 🎯