JPEG Compression in 2026: Why Jpegli Changes the Quality-Per-Byte Game
The problem: I have to deliver JPEG because the platform only accepts JPEG (eBay, Etsy, legacy CMS, print upload portals), but I still need smaller files without ugly artifacts. The old tools give me two bad choices—crank quality to 90 and bloat the file, or drop to 70 and watch detail collapse into blocky mush.
Modern JPEG encoders changed that trade-off. Google's jpegli library (released in 2024) delivers reported compression improvements of up to 35% at high quality settings while maintaining full compatibility with every JPEG viewer on the planet. This isn't a new format requiring browser support or user education—it's better math inside the same old container.
What's in This Guide
JPEG Encoder Comparison: 2026 Cheat Sheet
libjpeg-turbo
MozJPEG
jpegli
JPEG Basics That Matter for Performance
Progressive vs Baseline
Baseline JPEG loads top-to-bottom in one pass. The user sees nothing until the first scan lines arrive, then the image reveals itself linearly. For small images or fast connections, this works fine.
Progressive JPEG encodes the image in multiple scans—first a rough, blurry preview of the entire frame, then successive passes that refine detail. This improves perceived load speed (users see something immediately) and typically results in 2-10% smaller files for images over 10KB. The trade-off is slightly higher CPU cost during decode, which matters on older mobile devices but is negligible on modern hardware.
Chroma Subsampling
JPEG separates luminance (brightness) from chrominance (color). Most encoders subsample chroma to save bits—the human eye is less sensitive to color detail than brightness detail.
- 4:4:4 – No subsampling. Full color resolution. Larger files, best for graphics with sharp color transitions or text.
- 4:2:2 – Chroma sampled at half horizontal resolution. Moderate savings, good for high-quality photography.
- 4:2:0 – Chroma sampled at half resolution in both dimensions. Standard for web JPEGs. Saves the most space, acceptable for most photographic content.
If you're compressing product photos for eBay or marketing assets for email, 4:2:0 is fine. If you're exporting screenshots with UI text, force 4:4:4 or switch to PNG.
Quality Settings (and Why They're Misleading)
Every encoder defines "quality" differently. MozJPEG's 85 is not the same as libjpeg-turbo's 85. Jpegli's 90 produces smaller files than libjpeg-turbo's 90 at similar visual fidelity (in tests conducted by Google using crowdsourced raters and ELO scoring).
Don't trust the number. Trust your eyes and a file-size comparison at fixed visual quality.
Metadata and ICC Profiles
JPEG files can carry EXIF metadata (camera settings, GPS, timestamps) and ICC color profiles (how to interpret the RGB values). Stripping metadata reduces file size by a few KB—sometimes 10-20KB for a RAW-exported JPEG with embedded previews. ICC profiles are usually a few KB but essential for print workflows. For web delivery, sRGB is assumed, so stripping non-sRGB profiles is safe.
When JPEG Is Still the Right Choice
JPEG remains the best option when:
- The platform explicitly rejects modern formats (eBay, Etsy, many print labs, government portals).
- You need universal decode support (email clients, ancient browsers, embedded systems).
- You're archiving photographic content and want a format that will open in 2046.
- Encode speed matters more than the last 10% of compression efficiency.
JPEG is not the right choice for graphics with sharp edges (logos, diagrams, UI screenshots)—use PNG. For web delivery with modern browser support, AVIF and WebP deliver better compression. But when you're forced into JPEG, use the best encoder available.
What Jpegli Is: Better JPEG Encoding, Not a New Format
Jpegli is an advanced JPEG encoder (and decoder) released by Google in April 2024. It produces standard JPEG files that open in every image viewer, browser, and photo app—no special support required.
How It Remains Interoperable
Jpegli complies with the original JPEG standard (ISO/IEC 10918-1). The output is a .jpg file using the traditional 8-bit formalism. Any device or app that can display a JPEG from 2005 can display a JPEG from jpegli in 2026. There is no "jpegli format"—there's just JPEG, encoded more intelligently.
What "Better JPEG Encoding" Actually Means
Jpegli applies techniques originally developed for JPEG XL (a next-generation image format) to the constraints of classic JPEG. Specifically:
- Adaptive quantization heuristics – Jpegli spatially modulates the quantization dead zone based on psychovisual modeling (how the human eye perceives detail and noise). This means the encoder allocates more bits to visually important areas and fewer bits to areas where artifacts are less noticeable.
- Improved quantization matrix selection – The quantization matrices (which control how aggressively the DCT coefficients are rounded) were optimized for a mix of psychovisual quality metrics, not just mathematical distortion.
- Precise intermediate calculations – Both encoding and decoding use more accurate math, reducing cumulative rounding errors that degrade quality.
- XYB colorspace option – Jpegli can encode JPEG using the XYB colorspace (a perceptually uniform space developed for JPEG XL) via an embedded ICC profile, improving coding efficiency. This is an advanced feature not yet widely used in practice.
The result, as reported by Google in crowdsourced rater studies, is that jpegli at 2.8 bits-per-pixel (BPP) matched the visual quality of libjpeg-turbo at 3.7 BPP—a 32% reduction in bitrate, or equivalently, a 35% compression improvement at similar quality.
Why This Is Different from "New Formats" Like AVIF or JPEG XL
AVIF and JPEG XL are modern image formats with better compression than JPEG but require explicit browser/app support. As of 2026, AVIF has ~94% browser support, and JPEG XL support varies (Apple announced support in 2025, but adoption is still rolling out).
Jpegli doesn't require any browser updates. A jpegli-encoded JPEG is just a JPEG. The improvement is invisible to the decoder—it simply receives a smaller file that looks better.
Claims and Nuance: What the Tests Actually Show
Google's announcement cited a 35% compression improvement at high quality settings. This number comes from a specific methodology: crowdsourced raters comparing images from the Cloudinary Image Dataset '22, encoded at several bitrates using jpegli, libjpeg-turbo, and MozJPEG, with results aggregated using ELO scoring.
Important caveats:
- The 35% figure applies to high-quality settings (e.g., quality 90+). At medium quality (70-80), the gap narrows.
- The test used photographic content. Graphics, screenshots, and synthetic images may behave differently.
- The XYB colorspace mode was disabled in the Google study, as it is how most users would initially deploy jpegli.
- Independent tests (e.g., Gianni Rosato's analysis) show jpegli outperforms MozJPEG on some images but not all—results vary by content type.
Bottom line: Jpegli improves quality-per-byte in tests and reported real-world use, but it is not a universal 35% win on every image. Test it on your specific content at your target quality level.
Adoption Reality: Why Your Stack Probably Still Uses MozJPEG or libjpeg-turbo
libjpeg-turbo: The Default Everywhere
libjpeg-turbo is the default JPEG library in most Linux distributions and underpins countless image processing pipelines. It prioritizes speed—claiming 2-6x faster encoding/decoding than the original libjpeg. For high-throughput CDN edge nodes or batch pipelines processing millions of images, that speed matters more than the last 10% of compression efficiency.
MozJPEG: The Web Optimization Standard
MozJPEG (developed by Mozilla) improved on libjpeg-turbo's compression ratio, especially at medium quality settings, while maintaining API/ABI compatibility. It became the go-to encoder for web optimization workflows—ImageMagick, libvips, and many online compression tools default to MozJPEG when targeting JPEG output.
Jpegli: Newer and Not Yet Everywhere
Jpegli was released in April 2024. As of early 2026:
- Not in Lightroom – Adobe has not integrated jpegli into Lightroom Classic or Lightroom CC. Users have requested it on Adobe community forums.
- Not in mainstream tooling by default – ImageMagick and libvips support jpegli as an optional backend (if compiled with libjxl, which includes the
cjpeglibinary), but it is not the default. - Emerging in specialized tools – Privacy-focused and performance-oriented image optimizers (like Mochify) have adopted jpegli early, offering it as an explicit output option.
Why the slow rollout?
Established tools with massive installed bases move cautiously. MozJPEG is proven, stable, and "good enough" for most workflows. Jpegli requires recompilation with libjxl dependencies, which adds complexity. As jpegli matures and more benchmark data accumulates, expect gradual adoption—but don't expect Adobe or WordPress plugins to switch overnight.
Stop Uploading Bloated Files and Hoping the Platform Fixes Them
A disturbingly common workflow: shoot a 6MB JPEG from a DSLR, drag it into the eBay listing form, and hope eBay's backend recompresses it gracefully. It won't. eBay will hammer it with a generic lossy pass that obliterates fine detail, or reject it entirely for exceeding size limits.
The same applies to WordPress users who install five plugins (image optimization, lazy load, CDN integration, WebP conversion, and a caching layer) and wonder why their admin panel takes 8 seconds to load. Plugin bloat is real—each plugin adds database queries, background processes, and potential conflicts. Optimize your images before upload. Use an external tool, get the file size and format right, then import clean assets. Your server, your database, and your sanity will thank you.
Practical Workflows: Real Scenarios Where JPEG (and Jpegli) Matter
Workflow 1: "I Need JPEG for eBay/Etsy/Legacy CMS"
Problem: The platform only accepts JPEG. You have 200 product photos at 8MB each from a Fuji X-T5 shooting HIF/HEIF. eBay's limit is 12MB total per listing, and each photo should be under 1MB for fast mobile load.
Solution:
- Convert format first (if needed) – If your camera outputs HIF/HEIF/RAW, convert to JPEG. Tools like Mochify handle HIF-to-JPEG conversion with in-memory processing.
- Resize to platform specs – eBay recommends 1600×1600px. Etsy wants 2000-2400px width. Amazon specifies 2000×2000px minimum for zoom. Don't guess—check the current platform guidelines.
- Compress with jpegli – Use a quality setting that hits your target file size (typically 200-500KB per image for product photos). Jpegli at quality 85-90 will deliver better visual results than libjpeg-turbo or MozJPEG at the same file size (based on reported test results).
- Verify one image first – Encode one sample, upload it to the platform, check how it looks on desktop and mobile. If the platform recompresses on upload, you'll see it immediately.
Workflow 2: "I Can Serve WebP/AVIF but Need JPEG Fallback"
Problem: Your CDN or CMS serves AVIF to Chrome, WebP to Safari, and JPEG to legacy browsers/email clients. You need a high-quality JPEG fallback that doesn't bloat the origin server.
Solution:
- Store one source-quality master (PNG or lossless WebP/JPEG XL) at maximum resolution.
- Generate three variants on first request or at build time:
- AVIF at quality 60-70 (smallest file, best for modern browsers).
- WebP at quality 75-80 (broader compatibility than AVIF in 2026).
- JPEG (jpegli) at quality 85-90 (universal fallback, smaller than MozJPEG equivalent).
- Use
<picture>element orAcceptheader negotiation to serve the best format per client. - Cache aggressively – Generate once, serve from edge.
This workflow is common in Next.js/Cloudflare/Imgix pipelines. Jpegli as the fallback encoder shaves 15-30% off JPEG fallback size compared to libjpeg-turbo, which translates to measurable LCP improvements for users stuck on IE11 or ancient Android WebViews.
Workflow 3: "Photographer/Export Pipeline (Lightroom → Optimize → Client Delivery)"
Problem: You export 500 wedding photos from Lightroom at quality 90 (sRGB JPEG). Files are 3-5MB each. The client wants a Google Drive folder under 2GB total, and you want each image under 1MB for fast web gallery load.
Solution:
- Export from Lightroom at maximum quality (90-95) with sRGB color profile and no size limit. Do not resize or compress in Lightroom—Lightroom's JPEG encoder (as of 2026) still uses an older library, not jpegli.
- Batch process the exported JPEGs externally - Resize to 2560px long edge (sufficient for 4K display). Compress using jpegli at quality 85. Target 800KB-1.2MB per image.
- Strip unnecessary metadata - Remove GPS, camera serial numbers, and embedded thumbnails. Keep copyright EXIF if contractually required.
- Test decode compatibility - Open a few files in common client tools (Windows Photo Viewer, macOS Preview, Gmail image preview). Jpegli JPEGs are fully compatible, but it never hurts to verify before delivering 500 files.
A Repeatable Test Methodology: Compare Encoders on Your Content
Generic benchmarks (like Google's or Gianni Rosato's) are useful, but they tested their images. Your product photos, your hero images, your content may behave differently. Here's a methodology you can replicate in 30 minutes.
Step 1: Select 3-5 Representative Source Images
- Pick images that represent your actual use case (product photos, portraits, UI screenshots, etc.).
- Use high-quality originals (PNG, or JPEG at quality 95+, or camera RAW exported lossless).
- Include at least one image with gradients (sky, skin tone) and one with sharp edges (if applicable).
Step 2: Fix Dimensions and Normalize
Resize all images to your target output resolution (e.g., 2048px wide for web, 1600×1600px for eBay). Use a consistent resampling filter (Lanczos3 or similar).
Step 3: Encode with Multiple Encoders at Equal Target File Size
- Pick a target file size (e.g., 300KB).
- Encode each image with:
- libjpeg-turbo (adjust quality until file ≈ 300KB).
- MozJPEG (same process).
- jpegli (same process).
- Record the quality setting required to hit 300KB for each encoder.
Step 4: Measure Visual Quality
Subjective (best): Open all three versions side-by-side at 100% zoom. Look for blocking artifacts (8×8 squares), banding in gradients, loss of fine detail. Trust your eyes—metrics don't capture everything.
Objective (if available): Use SSIM or SSIMULACRA2 to compare each encoded version against the original. SSIM is outdated but widely available. SSIMULACRA2 is more perceptually accurate. Beware that metrics can mislead—an image with a higher SSIM score may still look worse to human eyes.
Step 5: Measure Encoding Time
If speed matters (batch processing thousands of images), time the encode:
time cjpegli input.png -q 85 output.jpg time cjpeg -quality 85 input.png > output_mozjpeg.jpg
Jpegli encoding speed is comparable to MozJPEG in most tests (70-100ms per image for typical web-resolution photos on modern CPUs).
Step 6: Document Settings and Results
Create a simple table:
libjpeg-turbo
MozJPEG
jpegli 4:2:0
This data is specific to your content and workflow. Use it to decide which encoder to adopt.
Mochify's Privacy-First JPEG Optimization
When you're forced to deliver JPEG—because eBay won't accept AVIF, or your client's print lab demands it, or the legacy CMS hasn't been updated since 2015—you want the best possible quality-per-byte without exposing your unpublished product photos or client assets to generic cloud processors that store files for "processing".
Mochify processes images entirely in RAM. The file streams into memory, gets compressed (using jpegli or other modern encoders), and is deleted the instant the download completes. Nothing touches the hard drive. No training data. No 24-hour retention window. Just ephemeral processing at C++20 speed.
Why this matters for JPEG workflows specifically
When you're exporting product photography for a new Shopify drop, or preparing 200 listings for eBay, you're handling unreleased inventory. A leaked product photo 48 hours before launch can cost thousands in competitive advantage. Zero-retention architecture eliminates that risk entirely.
Mochify supports jpegli output, which means you can compress to smaller file sizes at higher visual quality compared to tools still using libjpeg-turbo—without storing your images on someone else's server.
Try It: Compare Jpegli on One Real Image
Theory and benchmarks are useful, but your specific content behaves differently from test datasets. Pick one representative image and compress it with jpegli to see the quality-per-byte improvement for yourself.
Compress a JPEG with Mochify (Jpegli)FAQ: JPEG Optimization in 2026
Is jpegli just Google's version of MozJPEG?
No. MozJPEG improved on libjpeg-turbo primarily through better quantization and trellis optimization. Jpegli applies adaptive quantization heuristics from JPEG XL, improved matrix selection, and optionally uses the XYB colorspace—techniques MozJPEG doesn't use. In independent tests, jpegli outperforms MozJPEG on high-quality photographic content, though results vary by image.
Will jpegli-encoded JPEGs open on my iPhone?
Yes. Jpegli produces standard JPEG files fully compliant with ISO/IEC 10918-1. Every JPEG viewer, including iOS Photos, Android Gallery, Windows Photo Viewer, and every web browser, will open them without issue.
Can I use jpegli in Photoshop or Lightroom?
Not natively as of early 2026. Adobe has not integrated jpegli into their export pipelines. You can export from Lightroom at high quality, then recompress externally using a tool that supports jpegli (like Mochify or command-line cjpegli from libjxl).
Does jpegli support progressive JPEG?
Yes. Jpegli can encode both baseline and progressive JPEGs. Use progressive encoding for large images (hero images, product photos above 100KB) to improve perceived load speed.
How much smaller are jpegli files compared to MozJPEG?
It depends on the image and quality setting. Google's tests showed up to 35% smaller files at high quality (90+) compared to libjpeg-turbo, and smaller than MozJPEG in several scenarios. Independent tests show mixed results—sometimes 10-15% smaller, sometimes negligible. Test on your own content.
Should I switch all my existing JPEGs to jpegli?
Only if you need to reduce file size and are reprocessing assets anyway (e.g., resizing for a new platform, refreshing a product catalog). Recompressing an already-compressed JPEG introduces generation loss. If the current JPEG is "good enough," leave it.
What chroma subsampling should I use with jpegli?
For photographic content, 4:2:0 is standard and delivers the smallest files with minimal visible quality loss. For graphics, screenshots, or images with fine color detail (e.g., product photos with intricate patterns), test 4:2:2 or 4:4:4—the file will be larger, but color fidelity improves.
Does jpegli work with ICC color profiles?
Yes. Jpegli can embed ICC profiles (including sRGB and XYB). For web delivery, sRGB is safe to embed or assume. For print workflows, retain the original profile from your RAW processor.
Why isn't jpegli the default in WordPress plugins yet?
Adoption lag. WordPress image optimization plugins (ShortPixel, Smush, EWWW) are built around libjpeg-turbo and MozJPEG, which are stable, widely tested, and simple to deploy. Jpegli requires libjxl dependencies and was only released in 2024. Expect gradual adoption as jpegli proves itself in production at scale.
Is jpegli faster or slower than MozJPEG?
Comparable. Google's benchmarks and independent tests show jpegli encoding speed is similar to MozJPEG and faster than older tools like Guetzli. Decode speed is identical (they all produce standard JPEGs decoded by the same libraries).
Can I use jpegli for JPEG XL output?
No. Jpegli produces JPEG files, not JPEG XL files. JPEG XL is a separate next-generation format with better compression than JPEG but limited browser support as of 2026. If you want JPEG XL output, use cjxl from the libjxl toolkit.