Nice. I have a bash script similar to the one listed "removeexif" called prep_for_web which takes any image file (PNG, BMP, JPG, WebP), scrubs EXIF data, checks for transparency and then compresses it to either JPG using MozJPEG or to PNG using PNGQuant.
[1] https://github.com/mozilla/mozjpeg
[2] https://pngquant.org
In Scripts I wrote that I use all the timemozilla
mozjpeg
C2014–2025
mozilla / mozjpeg
mozjpeg
Improved JPEG encoder.
24Distinct people
28Mentions
0Explicit recommenders
5.7KGitHub stars
What to know before exploring
What it is
Improved JPEG encoder.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year28 dated mentions
Observed mentions: 2014-03-05 19:17:44 UTC to 2025-10-22 18:18:42 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 6 | 2 | 4 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Mozilla JPEG Encoder Project
MozJPEG improves JPEG compression efficiency achieving higher visual quality and smaller file sizes at the same time. It is compatible with the JPEG standard, and the vast majority of the world's deployed JPEG decoders.
MozJPEG is a patch for libjpeg-turbo. Please send pull requests to libjpeg-turbo if the changes aren't specific to newly-added MozJPEG-only compression code. This project aims to keep differences with libjpeg-turbo minimal, so whenever possible, improvements and bug fixes should go there first.
MozJPEG is compatible with the libjpeg API and ABI. It is intended to be a drop-in replacement for libjpeg. MozJPEG is a strict superset of libjpeg-turbo's functionality. All MozJPEG's improvements can be disabled at run time, and in that case it behaves exactly like libjpeg-turbo.
MozJPEG is meant to be used as a library in graphics programs and image processing tools. We include a demo cjpeg command-line tool, but it's not intended for serious use. We encourage authors of graphics programs to use libjpeg's C API and link with MozJPEG library instead.
Features
Progressive encoding with "jpegrescan" optimization. It can be applied to any JPEG file (with jpegtran) to losslessly reduce file size.
Trellis quantization. When converting other formats to JPEG it maximizes quality/filesize ratio.
Comes with new quantization table presets, e.g. tuned for high-resolution displays.
Fully compatible with all web browsers.
Can be seamlessly integrated into any program that uses the industry-standard libjpeg API. There's no need to write any MozJPEG-specific integration code.
Releases
Latest release
Overview of 3.0 features
Version 2.0 Announcement
Version 1.0 Announcement
Compiling
See BUILDING. MozJPEG is built exactly the same way as libjpeg-turbo, so if you need additional help please consult libjpeg-turbo documentation.
Read the full README on GitHubWhat Hacker News says
28 sourcesIt took a bit of time for me to respond because I wanted to make sure I wrote down the info in a nice detailed way. I will update the descriptions on the website to include the information I am proving here to give visitors a better understanding of the options. To be clear, I am not an expert on all this image coding stuff. I just wanted to make a simple tool to let people try out Jpegli because I thought it was interesting even though I don't know so much about the topic.
Progressive Rendering
There are 3 options on the website. None, Basic and Enhanced. There correspond respectively to options 0, 1 and 2 for the JXL_ENC_FRAME_SETTING_PROGRESSIVE_DC option [1].
"Set the progressive mode using lower-resolution DC images for VarDCT. Use -1 for the encoder default, 0 to disable, 1 to have an extra 64x64 lower resolution pass, 2 to have a 5
Read the rest
12x512 and 64x64 lower resolution pass."
So "Basic" provides 1 scan and "Enhanced" provides 2 scans. Here is a detailed description on progressive loading: https://www.thewebmaster.com/progressive-jpegs/
DCT Method
I can't really find documentation about DTC Method in libjxl but the options seems to be very similar to the options offered in mozjpeg [2]. They have a detailed explanation on that page I referenced which I won't all copy here. Seems like slow integer is the preferred method as the others are marked as legacy. Maybe I should just remove the options? From my testing the slow integer method has slightly worse compression but it is accurate.
XYB colorspace
TBH, the library I am using only supports a few color spaces and it does not include XYB and I have not looked into it much further. Also as you can see I did not really bother to add colorspace settings in general but I might do it later.
[1] https://libjxl.readthedocs.io/en/latest/api_encoder.html#_CP...
[2] https://github.com/mozilla/mozjpeg/blob/6c9f0897afa1c2738d72...
Depends on the format I'm targeting.
PNG: zopflipng https://github.com/google/zopfli/blob/master/README.zopflipn...
AVIF: libavif https://github.com/AOMediaCodec/libavif
JPG (for backwards compatibility when there's no AVIF): mozjpeg https://github.com/mozilla/mozjpeg
In Ask HN: What's your preferred tool or library for image compression?From my own experience, JPEG quality and compression efficiency can differ a lot depending on the encoder implementation. It would make more sense to compare specific encoders rather than formats in general.
In 2014 (WebP was released in 2010) Mozilla claimed that the standard JPEG format is not used to it's full potential [1] and introduced mozjpeg project that is still being updated [2]. I wonder how it compares today with current WebP implementations.
[1] https://research.mozilla.org/2014/03/05/introducing-the-mozj...
[2] https://github.com/mozilla/mozjpeg
In WebP is so great except it's not (2021)It would be nice if the author would add mozjpeg[1] to the comparison. At certain image resolutions, it can produce smaller file sizes than WebP, and because it is still a jpeg, it has a much better compatibility story, which the author alluded to.
[1]https://github.com/mozilla/mozjpeg
In It's the future – you can stop using JPEGs> MozJPEG is a patch for libjpeg-turbo. Please send pull requests to libjpeg-turbo if the changes aren't specific to newly-added MozJPEG-only compression code.
https://github.com/mozilla/mozjpeg#mozilla-jpeg-encoder-proj...
In JPEG XL: How it started, how it’s goingFWIW, Mozilla has been maintaining their own fork for quite a while now[1]
But AFAIK most Linux Distros have been using libjpeg-turbo as a drop-in replacement for libjpeg, after some drama in ~2010 where libjpeg came under new management, decided to break ABI/API several times over and add incompatible, non-standard format extensions[2].
[1] https://github.com/mozilla/mozjpeg
[2] https://en.wikipedia.org/wiki/Libjpeg#History
In libjpeg-turbo 3.0 has been released, and why there may never be a 3.1No.
See https://github.com/mozilla/mozjpeg
Also, there is a fairly big problem with JPG that the ‘quality’ setting is not calibrated. That is you might look at one image and think it looks fine (which is subjective, depends on what you want to use the image for…) with a quality of 60%, but then you compress a million images at that rate, delete the originals, then you find that many of them look really awful. Not only that but there are images you could have compressed more and still been happy with the output.
If you are publishing images for the web consider using WebP which is consistently better, well supported now, and has a calibrated quality knob.
In Are all JPEG compression implementations the same?Guetzli was already mentioned and roughly does what you are talking about.
MozJPEG [1] includes several quantization tables that are optimized for different contexts (see the quant-table flag and source code for specific tables[2]), and the default quantization table has been optimized to outperform the recommended quantization tables in the original JPEG spec (Annex K).
It's also worth noting that MozJPEG uses Trellis quantization [3] to help improve quality without a per-image quantization table search. Basically rather than determining an optimal quantization table for the image, it minimizes rate distortion on a per-block level by tuning the quantized coefficients.
Both the SSIM and PSNR tuned quantization tables (2 and 4) provided by MozJPEG use a lower value in the first position of the quantization just like this article suggests (
Read the rest
9 and 12 vs the libjpeg default of 16).
[1] https://github.com/mozilla/mozjpeg
[2] https://github.com/mozilla/mozjpeg/blob/5c6a0f0971edf1ed3cf3...
[3] https://en.wikipedia.org/wiki/Trellis_quantization
It was not badly picked for regular use cases. Just, before the retina displays appeared no one was interested in extreme low bitrate and no one knew that different artifacts had different impact with high density.
At least this problem was highlighted by Kornel, one of the mozjpeg author here: https://github.com/mozilla/mozjpeg/issues/76
> the employed solution only modifies first element from [16,17] to [10,16].
Correction: 16 and 17 are values from the base tables, which means this table is used with q=50. With q=25 it will be [32, 22, 24, 28, 24, 20, 32, 28…] (in zigzag order). The employed solution is to always limit the first value by 10 regardless of q: [10, 22, 24, 28, 24, 20, 32, 28…]
mozjpeg chosen the different approach: it still scales all values based on q, but has significantly changed the default base table. It helps, but d
Read the rest
oesn't eliminate color banding completely (you can still see it on the example from issues/76).
They're still being used. A newer, optimized JPEG encoder, mozJPEG[0], seems to use progressive encoding by default. I suspect with faster internet speeds, most JPEGs download and decode so fast that the cool 'enhance' animation is rarely seen anymore.
[0] https://github.com/mozilla/mozjpeg
In FFmpeg now supports JPEG XLmozjpeg greatly improved the state of art jpeg encodig, while maintaining full backwards compatibility https://github.com/mozilla/mozjpeg
but there's a limit on what can be done with the primitives that jpeg offers. for example, jpeg is stuck with the older huffman coding for the entropy encoding part, instead of the better arithmetic coding or asymetric numeral systems
In AVIF has landed (2020)A link to https://jpeg.rocks/ was posted here:
https://news.ycombinator.com/item?id=25712301
This is based on https://github.com/mozilla/mozjpeg, which is a patched version of https://github.com/libjpeg-turbo/libjpeg-turbo
In The Future of Libjpeg-TurboIMHO these JPEG optimizers need to explain what optimization they actually do.
At the very least, it should mention if the optimization is lossless (by dropping metadata, optimizing Huffman table/progressive scan parameters etc.) or lossy: because they have very different use cases (sometimes you need the image to be pixel-wise identical).
Even better, if lossy, "how lossy" it is.
I'm aware it's using mozjpeg [1] which is pretty good (guetzli [2] is another good one for the interested); still, it comes with many settings and routines (both lossless and lossy) that can be configured.
[1] https://github.com/mozilla/mozjpeg
[2] https://github.com/google/guetzli
In Show HN: JPEG.rocks – Privacy-aware JPEG optimizer built with WebAssemblyYes, this is definitely an interesting question. Earlier this year I implemented a version of trellis quantization for some compression experiments that I've been tinkering with in my spare time. My code considers more possibilities than just rounding to the nearest quantization step when it deems that the bit rate savings in after entropy encoding may be worth the additional image loss (e.g., it might even completely zero a coefficient). That would violate this decoder's assumption that the original DCT coefficient must have been within a limited range around the quantization step.
I know that mozjpeg [1] features trellis quantization for JPEG encoding. I wonder how this decoder would do with that?
[1] https://github.com/mozilla/mozjpeg
In Jpeg2png: Silky smooth JPEG decoding – no more artifacts (2016)Showing the 15 most recent of 28 sources. Enable JavaScript to search and browse every indexed mention.