JPEGLI = A small JPEG
The suffix -li is used in Swiss German dialects. It forms a diminutive of the root word, by adding -li to the end of the root word to convey the smallness of the object and to convey a sense of intimacy or endearment.
This obviously comes out of Google Zürich.
Other notable Google projects using Swiss German:
https://github.com/google/gipfeli high-speed compression
Gipfeli = Croissant
https://github.com/google/guetzli perceptual JPEG encoder
Guetzli = Cookie
https://github.com/weggli-rs/weggli semantic search tool
Weggli = Bread roll
https://github.com/google/brotli lossless compression
Brötli = Small bread
In Jpegli: A new JPEG coding librarygoogle
guetzli
C++2016–2024
google / guetzli · Archived
guetzli
Perceptual JPEG encoder
23Distinct people
23Mentions
0Explicit recommenders
12.9KGitHub stars
What to know before exploring
What it is
Perceptual 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, 3:03:16 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 year23 dated mentions
Observed mentions: 2016-10-21 21:27:47 UTC to 2024-04-03 21:54:29 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 |
|---|---|---|---|---|---|
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 7 | 2 | 5 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 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 | 2 | 1 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-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
Introduction
Guetzli is a JPEG encoder that aims for excellent compression density at high
visual quality. Guetzli-generated images are typically 20-30% smaller than
images of equivalent quality generated by libjpeg. Guetzli generates only
sequential (nonprogressive) JPEGs due to faster decompression speeds they offer.
Building
On POSIX systems
Get a copy of the source code, either by cloning this repository, or by
downloading an
archive and
unpacking it.
Install libpng.
If using your operating system
package manager, install development versions of the packages if the
distinction exists.
On Ubuntu, do apt-get install libpng-dev.
On Fedora, do dnf install libpng-devel.
On Arch Linux, do pacman -S libpng.
On Alpine Linux, do apk add libpng-dev.
Run make and expect the binary to be created in bin/Release/guetzli.
On Windows
Get a copy of the source code, either by cloning this repository, or by
downloading an
archive and
unpacking it.
Install Visual Studio 2015 and
vcpkg
Install libpng using vcpkg: .\vcpkg install libpng.
Cause the installed packages to be available system-wide: .\vcpkg integrate install. If you prefer not to do this, refer to vcpkg's
documentation.
Open the Visual Studio project enclosed in the repository and build it.
On macOS
To install using Homebrew:
Install Homebrew
brew install guetzli
To install using the repository:
Get a copy of the source code, either by cloning this repository, or by
downloading an
archive and
unpacking it.
Install Homebrew or MacPorts
Install libpng
Using Homebrew: brew install libpng.
Using MacPorts: port install libpng (You may need to use sudo).
Run the following command to build the binary in bin/Release/guetzli.
If you installed using Homebrew simply use make
If you installed using MacPorts use CFLAGS='-I/opt/local/include' LDFLAGS='-L/opt/local/lib' make
With Bazel
There's also a Bazel build configuration provided. If you
have Bazel installed, you can also compile Guetzli by running bazel build -c opt //:guetzli.
Using
Note: Guetzli uses a large amount of memory. You should provide 300MB of
memory per 1MPix of the input image.
Note: Guetzli uses a significant amount of CPU time. You should count on
using about 1 minute of CPU per 1 MPix of input image.
Note: Guetzli assumes that input is in sRGB profile with a gamma of
2.2. Guetzli will ignore any color-profile metadata in the image.
To try out Guetzli you need to build or
download the Guetzli binary. The
binary reads a PNG or JPEG image and creates an optimized JPEG image:
guetzli [--quality Q] [--verbose] original.png output.jpg
guetzli [--quality Q] [--verbose] original.jpg output.jpg
Note that Guetzli is designed to work on high quality images. You should always
prefer providing uncompressed input images (e.g. that haven't been already
compressed with any JPEG encoders, including Guetzli). While it will work on other
images too, results will be poorer. You can try compressing an enclosed sample
high quality
image.
You can pass a --quality Q parameter to set quality in units equivalent to
libjpeg quality. You can also pass a --verbose flag to see a trace of encoding
attempts made.
Please note that JPEG images do not support alpha channel (transparency). If the
input is a PNG with an alpha channel, it will be overlaid on black background
before encoding.
Read the full README on GitHubWhat Hacker News says
23 sourcesThere is google compression https://github.com/google/guetzli
In NASA ICER image compression algorithm as a C libraryGuetzli. Looks like development has stalled? Perhaps for just that reason.
https://github.com/google/guetzli
In Losslessly Optimising ImagesI've never had much luck using jpegoptim. In most cases it's only removing the metadata, which isn't much on high-res files.
Guetzli is nice, if you don't have too many images to recompress (quite slow): https://github.com/google/guetzli
In Losslessly Optimising ImagesTurns out there is a project which does that: https://github.com/google/guetzli
In Fighting JPEG color bandingYou know. I was actually quite annoyed ( to say the least ) with the post. For one the post is lacking a date, and you have to search yourself it was published in April 2017. And without a date the article is completely lacking context because Guetzli [1] hasn't been worked on for 5 years. And as [2] mentioned its work and derivative was ultimately merged into JPEG XL, which is a very decent image format. ( People should definitely check out JPEG XL if it is not on your radar yet )
But then I notice it was Dan luu who submitted it, which likely means there must be something much deeper than is what is shown on the surface. So what is the context here ?
[1] https://github.com/google/guetzli
[2] https://news.ycombinator.com/item?id=30622303
In Guetzli vs. MozJPEGFYI: Guetzli seems to have not been touched in ~5 years.
See https://github.com/google/guetzli/tree/master/guetzli
In Guetzli vs. MozJPEGGuetzli – Perceptual JPEG Encoder
4 points · Open discussionIMHO 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 WebAssemblyGuetzli: Perceptual JPEG Encoder
1 points · Open discussionI'm surprised this doesn't include Google Guetzli (https://github.com/google/guetzli) in the comparison. In my experience trying to optimize product images for an eCommerce site, this provided the best compression. Yes, it's ridiculously slow, but for encode-once-transmit-often scenarios, it's perfectly usable.
In Is WebP really better than JPEG?> Guetzli is not appropriate as a general-purpose tool for optimizing website images. That's not really what it's designed for.
What is it designed for? I downloaded and compiled it, and it seems to work quite well for the photographs on my website. The README says:
> Guetzli is a JPEG encoder that aims for excellent compression density at high visual quality
https://github.com/google/guetzli/
In Image optimization decreased website's page weight by 62%This article like many others is full of fallacies.
Image formats are not used wisely: [1] is PNG not JPEG and [2] is JPEG not PNG.
> I found that setting quality (mozjpeg) to 70 produces good enough images for the most part, but your mileage may vary.
You can get away with this setting for hidpi sizes but 1x will look horrible [1]. If you care about quality, the mileage is actually 75-95.
> (Pngquant) quality level of 65-80 to provide a good compromise between file size and image quality
Again, it may only be applied to hidpi sizes, and it will easily ruin any gradients or previously quantized images.
Pngquant is a great color quantization tool but it does not actually perform any lossless PNG optimizations, which can save you at least 5% more, and up to 90% in some cases.
All of these tools will also blindly strip metadata (but it's not
Read the rest
guaranteed!) along with color profiles and Exif Orientation resulting in color shifts and image transformations respectively.
Most importantly, none of them are good enough for automatic lossy compression. Guetzli is the closest but it still has some severe issues [3]. I'm also trying to build a real thing, and it is hard.
> there’s value in using WebP formats where possible
WebP lossless and WebP lossy are quite different formats. WebP lossy being always 4:2:0 is not a good replacement for JPEG [4] especially at higher quality. On the contrary WebP lossless has evolved into a decent alternative for PNG including lossy [5].
Proper responsive images would give you considerably smaller page weight and improve performance on mobile devices. BTW Google treats oversized images as unoptimized [6].
[1] https://freshman.tech/assets/dist/images/http-status-codes/e...
[2] https://freshman.tech/assets/dist/images/articles/freshman-1...
[3] https://github.com/google/guetzli/issues
[4] https://research.mozilla.org/2014/07/15/mozilla-advances-jpe...
[5] https://twitter.com/jyzg/status/958629795692150790
[6] https://developers.google.com/speed/pagespeed/insights/?url=...
And this is how people keep making substantial improvements to ancient formats like JPEG or MP3.
E.g. Guetzli from Google: https://github.com/google/guetzli/blob/master/README.md
In Rav1e: An experimental AV1 video encoder, designed to be fast and safeSorry for that. See the following for a likely reason and workaround:
https://github.com/google/guetzli/issues/40#issuecomment-287...
In Guetzli: A New Open-Source JPEG EncoderShowing the 15 most recent of 23 sources. Enable JavaScript to search and browse every indexed mention.