TinyPNG

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me image compression that replaces TinyPNG: files half the size with no visible difference, running in my own build.

STACK
- Node 20+ with sharp, plus the specialist encoders where they beat it
- Run as a build step and a small command-line tool. A hosted service is optional and mostly unnecessary
- SQLite through better-sqlite3 only if you want a cache index across builds

WHAT ACTUALLY MAKES A FILE SMALLER
- For PNG: quantise to a palette. Reducing 16 million colours to 256 chosen well is where the enormous savings come from, and it is what the service being replaced does. pngquant or an equivalent, with a quality range rather than a fixed number of colours, then a lossless pass with oxipng or zopfli
- For JPEG: re-encode at a sensible quality with mozjpeg's trellis quantisation and progressive scans. Progressive is both smaller and better to look at on a slow connection
- For both: strip metadata — EXIF, colour profiles, thumbnails — except the colour profile when the image is not sRGB, because stripping that shifts every colour
- Then: do not ship either format. WebP is typically 25 to 35 per cent smaller than a good JPEG, AVIF more again at the cost of much slower encoding. Serve those with a fallback, and the format choice saves more than any amount of tuning within a format

THE QUALITY QUESTION, WHICH IS THE WHOLE CRAFT
- A fixed quality number is the wrong approach: quality 80 is wasteful on a flat illustration and visibly bad on a photograph of foliage
- Target a perceptual metric instead. Encode at several qualities, measure each against the original with SSIM or, better, butteraugli or ssimulacra, and pick the smallest file that stays above the threshold
- That loop is a few seconds per image and it is the difference between guessing and knowing. Cache the result by content hash so it happens once per image, ever
- Set the threshold by looking: run a page of your own images through it, view them at real size on a real screen, and adjust. Do not trust a number you have not calibrated by eye

THE PIPELINE
- Input: any source image, at whatever resolution the designer exported
- Resize to the sizes actually used, from a declared list, with a good resampling kernel. Serving a 4000-pixel image into a 400-pixel slot is the single largest waste on most sites and no compressor fixes it
- Generate each size in each format
- Emit the width and height so the markup can reserve space, because layout shift is a worse user experience than a large file
- Output a manifest mapping the source to every derivative, which the templates read to build a srcset

THE CACHE
- Key on the content hash plus every option. An unchanged image is never re-encoded, and a build that re-encodes everything is a build nobody runs
- Store the chosen quality alongside, so the expensive search happens once
- Cache shared across builds and committed or stored centrally, so CI benefits too

WHAT TO WATCH FOR
- Alpha channels: quantising an image with transparency badly produces fringing. Test with a logo on a coloured background
- Animated GIFs: convert to video or animated WebP, which is usually ten times smaller. A GIF is a terrible video format
- Photographs of text and screenshots: these compress badly and artefact visibly. Detect them by edge density and use a higher threshold, or keep them lossless
- Very small images: below a few kilobytes the format overhead dominates and the savings are not worth a second request. Consider inlining them
- SVG: not this pipeline's job, but run it through an SVG optimiser and be aware that some optimisations break animations

THE COMMAND LINE
- One command over a directory, printing what changed: source, original size, output size, chosen quality, measured similarity
- A dry run that reports the savings without writing
- A check for CI that fails if any committed image exceeds a budget, which is how a site stops slowly filling with 4-megabyte hero images

THE HOSTED PART, IF YOU WANT IT
- An endpoint that transforms on demand with signed parameters, so nobody can use your server as a free image farm, and an immutable cache keyed on the parameters
- Useful only for user-uploaded images. Your own assets belong in the build, where they cost nothing at request time

WHAT MATTERS MOST
The perceptual quality search and resizing to the sizes actually used. Those two together typically beat any fixed-quality compressor, including the paid one, and the second is usually the larger win by far.

Give me the repository, the CLI, the build integration, the cache, the CI budget check, and a README with the format decisions and the calibration procedure written out.