How to Compress Images on Linux: A 2026 Toolkit

If you publish anything on the web, image weight is still one of the easiest places to win back page-load time. The original version of this post (back in 2013) recommended a single tool: Trimage, a small drag-and-drop GUI that wraps the standard Linux optimizers. Trimage is still around and still does its job. The toolbox around it, though, has grown a lot. There is now a modern GTK4 GUI called Curtail that handles both lossless and lossy compression, a much faster Rust rewrite of optipng called oxipng, and first-class command-line encoders for WebP and AVIF. So this is a refreshed 2026 walkthrough: the GUIs you can drag images onto, the CLI tools you can script, and a short matrix at the end for “which one should I actually reach for.”

All install commands assume Ubuntu 24.04 (Noble) or newer. Most of these tools are in Debian and Fedora repos too, sometimes under slightly different package names. If you are new to installing software on Ubuntu, the older Software Center walkthrough covers the GUI side; the rest of this guide sticks to apt.

Read this first: work on copies

Several of the tools below are happy to overwrite the original file in place. That is convenient for one-off cleanup of a build directory; it is a disaster when you point them at the only copy of a wedding photo. The defaults to watch out for:

• Trimage losslessly compresses each file you drop in and writes the result back to the original path.
• jpegoptim modifies input files by default. The man page is explicit: “By default jpegoptim modifies the input files (if they are optimized), to preserve original files use option -d to specify alternate directory for saving the optimized files to” (Debian man page).
• optipng also optimizes PNGs in place by default; pass -out (or -dir) to write the optimized copy somewhere else.
• oxipng overwrites the input file by default unless you pass --out (single file) or --dir (whole directory).
• mogrify (the ImageMagick batch tool) also overwrites in place: “This tool is similar to magick except that the original image file is overwritten” (ImageMagick docs).

The rule is the same in every case: copy first, optimize second. A simple cp -r originals/ optimized/ before you run anything keeps you out of trouble. If you are wiring this into a build step, point the tools at a build directory that is already a copy.

Trimage: still the easiest drag-and-drop GUI

Trimage’s pitch has not changed. It is “a cross-platform tool for losslessly optimizing PNG and JPG files for web” that internally calls “optipng, pngcrush, advpng and jpegoptim, depending on the filetype,” and it strips EXIF and other metadata on the way through (trimage.org). Open it, drag images in, wait a second or two per file, done. The compression is lossless, so the output is visually identical to the input. The win is removing metadata and squeezing the file headers, which typically saves 10 to 30 percent on a PNG and a smaller (but still real) amount on a JPEG that has not already been optimized.

Worth noting up front: Trimage is no longer under active upstream development (the last upstream release was in 2019), but it is still packaged in Ubuntu and still works fine because the underlying optimizers it calls out to (optipng, jpegoptim, advpng, pngcrush) are. Treat it as a stable utility rather than a frequently updated app.

Install on Ubuntu:

sudo apt install trimage

Trimage is the right answer when somebody hands you a folder of images and you want them lighter without thinking about it. It is the wrong answer when you need lossy compression, WebP, AVIF, or batch automation; for those, keep reading.

Curtail: the modern Flatpak GUI

Curtail is the spiritual successor to Trimage on the GNOME side. It is a GTK4 / Libadwaita app, part of GNOME Circle, and it ships through Flathub. It optimizes PNG, JPEG, WebP, and SVG files (note that it optimizes existing WebP files, rather than converting JPEG or PNG into WebP), and it offers both lossless and lossy modes with a toggle for keeping or stripping metadata. Under the hood it leans on the same Linux utilities (oxipng, pngquant, jpegoptim, libwebp, scour).

Install via Flatpak:

flatpak install flathub com.github.huluti.Curtail

If you have Flatpak set up already (Ubuntu 24.04 does not by default), Curtail is what I would hand to a friend who wants a single app that covers most web cases. The lossy mode is the reason: a JPEG run through Curtail at “lossy” with metadata stripped will be substantially smaller than the same JPEG through Trimage. If you need to actually convert JPEG or PNG to WebP or AVIF (not just shrink the bytes), reach for cwebp or avifenc further down.

jpegoptim: the JPEG workhorse on the CLI

jpegoptim is the tool to know for JPEGs at the command line. It is lossless by default (it rebuilds the Huffman tables to squeeze a few percent without changing pixels), but its lossy and target-size modes are where it earns its keep.

sudo apt install jpegoptim

A lossless pass that also strips EXIF, color profiles, and other markers:

jpegoptim --strip-all photo.jpg

A lossy pass capped at quality 85, which is the “this is the only setting you need most of the time” sweet spot for web JPEGs:

jpegoptim --strip-all --max=85 photo.jpg

A target size (useful when something is paginated and you want each image roughly under 200 KB). --size tries to reach the target size on a best-effort basis: it adjusts quality to get close, but the result may land a bit above or below and is not guaranteed to hit it exactly. Pair it with --max to cap the maximum quality.

jpegoptim --strip-all --size=200k photo.jpg

If you want to preserve the originals, send output to a separate directory with -d:

mkdir -p optimized
jpegoptim --strip-all --max=85 -d optimized *.jpg

For a whole tree of JPEGs, the standard find incantation works:

find . -type f -iname "*.jpg" -exec jpegoptim --strip-all --max=85 {} +

optipng and oxipng: PNG, slow vs fast

optipng is the classic lossless PNG optimizer. It is the tool Trimage calls in the background. Run it directly when you want explicit control:

sudo apt install optipng
optipng -o2 -strip all image.png

The -o level goes from 0 (fastest) to 7 (very slow); -o2 is the default and a sensible balance. -strip all drops metadata.

The reason to graduate from optipng is oxipng, a multi-threaded rewrite in Rust that “began in 2015 as a rewrite of the OptiPNG project.” It typically produces files that match or beat optipng’s output, and it runs several times faster on multi-core machines because it parallelises by default. The catch on Ubuntu 24.04 is that oxipng is not in the apt repos yet, so you install it through Cargo or grab a static binary from the release page:

# Option 1: Cargo (requires rustc / cargo installed)
cargo install oxipng

# Option 2: prebuilt binary
# Download from https://github.com/oxipng/oxipng/releases

Once installed, the call shape mirrors optipng:

oxipng -o 2 --strip safe image.png

--strip safe removes metadata that does not affect rendering; --strip all is more aggressive. For a directory of PNGs, oxipng takes a list of files and will use all your cores without help:

oxipng -o 2 --strip safe *.png

If you are running a Hugo or Astro build that touches hundreds of PNGs at deploy time, oxipng is the upgrade. If you are optimizing a handful of screenshots by hand, optipng from apt is fine.

ImageMagick: the swiss army knife

ImageMagick is not a dedicated compressor, but it is the tool to reach for whenever the task is “compress AND something else”: resize, convert formats, batch a whole directory, normalize color profiles. The companion command for in-place batch processing is mogrify, which is the same in both major versions.

sudo apt install imagemagick

One important version note: Ubuntu 24.04 (Noble) ships ImageMagick 6.9, where the per-image command is convert. ImageMagick 7 introduced the unified magick command, and that version lands in Ubuntu starting with 26.04. Everything below uses the same flags either way; only the command name changes. If you are not sure which release you are on, check your Ubuntu version from the terminal first.

Resize, strip metadata, and re-encode at quality 85, writing to a new file. On Ubuntu 24.04 (ImageMagick 6.9):

convert photo.jpg -resize 1600x1600\> -strip -quality 85 photo-web.jpg

On Ubuntu 26.04 (ImageMagick 7), the equivalent is:

magick photo.jpg -resize 1600x1600\> -strip -quality 85 photo-web.jpg

The 1600x1600\> form (“the > means only shrink, never enlarge”) is the right default for web images: it caps the longest edge at 1600 pixels without scaling smaller images up.

For a whole directory, mogrify is the batch version (and the command name does not change between IM6 and IM7). Remember the caveat: it overwrites in place unless you change the format. This command resizes and re-encodes every .jpg in the current directory, overwriting each one:

mogrify -resize 1600x1600\> -strip -quality 85 *.jpg

If you want a copy, route the output through -format and a different extension, or just cp -r first. The official -strip option is documented in the command-line options reference and removes embedded metadata across formats.

ImageMagick is also the easiest way to convert formats at the command line. Need a directory of PNGs as JPEGs? mogrify -format jpg -quality 85 *.png writes new files alongside the originals. Need to convert a single CR3 raw to a 2400px web JPEG with sRGB color? One convert or magick line, depending on your Ubuntu version. The dedicated WebP and AVIF tools below produce smaller files than ImageMagick’s WebP / AVIF output, so reach for them when format is the priority.

cwebp: convert to WebP

WebP is Google’s image format, well supported in every modern browser since 2020, and the file-size win over JPEG is real (typically 25 to 35 percent at matching visual quality). The reference encoder is cwebp, which is part of libwebp.

sudo apt install webp

A lossy conversion at quality 80, a common web-photo choice slightly above cwebp’s default of 75:

cwebp -q 80 photo.jpg -o photo.webp

A lossless conversion, useful for graphics with sharp edges:

cwebp -lossless graphic.png -o graphic.webp

The -m flag (effort, 0 to 6, default 4) trades encoding speed for slightly better compression. Bump to -m 6 on a build server where you do not care about the few extra seconds.

Google’s own cwebp documentation is the authoritative reference for the rest of the flags. There is also a companion dwebp for decoding back to PNG / TIFF if you ever need to inspect the result.

avifenc: convert to AVIF

AVIF is the newer format, smaller than WebP at comparable quality, and supported in Chrome, Firefox, and Safari since 2022 to 2023. The reference encoder is avifenc, shipped on Ubuntu in the libavif-bin package.

sudo apt install libavif-bin

Quality control on avifenc is the place where the Ubuntu version matters. The simple -q / --qcolor percentage flag (0 = worst, 100 = lossless) was added in newer libavif releases and is available on Ubuntu 26.04, but Ubuntu 24.04 ships libavif 1.0.4 where you need to use the older AV1 quantizer flags --min and --max (0 = best quality, 63 = worst). A reasonable lossy conversion on Ubuntu 24.04:

avifenc --min 0 --max 40 photo.jpg photo.avif

The same intent on Ubuntu 26.04 (or anywhere with a newer libavif) is the simpler:

avifenc -q 70 photo.jpg photo.avif

A lossless conversion works on both versions:

avifenc --lossless graphic.png graphic.avif

The default encoder speed is 6, on a scale of 0 (slowest, best compression) to 10 (fastest). Drop to -s 4 on a build server for noticeably smaller files at the cost of CPU time. -j all tells it to use every core.

AVIF support is now broad enough that an <img srcset> with both .avif and .webp sources, plus a .jpg fallback, is a reasonable production pattern. The new-format files are smaller; the JPEG fallback covers the edge cases.

Which tool for which job

The table below is the cheat sheet I keep in my head. It is not exhaustive (you can always reach for ImageMagick), but it covers most of the real workflows.

A reasonable shipping pipeline for a static site in 2026 looks like: resize with ImageMagick to a sensible max width, compress JPEGs with jpegoptim, compress PNGs with oxipng, then generate AVIF and WebP siblings of each with avifenc and cwebp. That sounds like a lot, but it is five short shell loops in a Makefile and it cuts a typical image folder by 50 to 80 percent.

A note on the original Trimage recommendation

The 2013 version of this post recommended Trimage as the single answer to “how do I make my images smaller on Linux?” That recommendation still holds for the narrow case it was written for: take a folder of images that arrived from somebody else, get them smaller without thinking, move on. What changed in the thirteen years since is that “smaller without thinking” is no longer the only goal worth optimizing for. WebP and AVIF exist; multi-core machines exist; build pipelines exist. The Trimage drop-zone is still a perfectly good front door, and Curtail is a nicer one if you live in GNOME. The CLI tools are where the bigger savings hide. Most of them are in Ubuntu’s repositories (jpegoptim, optipng, imagemagick, webp, libavif-bin), with Curtail installed via Flatpak from Flathub and oxipng installed via Cargo or its GitHub release binaries.