AI Image Compression and Conversion: Describe the Result, Skip the Settings

The real problem: image settings are a guessing game

Getting images right is hard because the decision is multi-dimensional: format, quality, dimensions, responsive sizing, and the lossless-versus-lossy trade-off all interact, and there is no single correct answer for every image. Google's own optimisation guidance calls image optimisation "both an art and a science," which is a polite way of saying most people are guessing.

The first trap is format choice. MDN's image-format guide lists a long menu of web image types, each with different compression behaviour, transparency support, and browser compatibility. Pick "just JPEG" out of habit and you can easily ship double the bytes you need. The second trap is quality and effort settings: web.dev's compression guidance notes that most images can be heavily compressed with little visible loss, but the right value has to be found by eye, and it changes with the content of each image. The usual sweet spot sits somewhere around 65 to 85 percent quality, except when it does not.

Then there is sizing. A camera produces a 6000px-wide file; your layout shows it at 1600px. Serving the original means the browser downloads roughly four times the pixels it can use. Responsive markup (srcset, sizes, and <picture>) fixes this, but it asks content editors to reason about layout width, device pixel ratio, and art-direction crops. That is well beyond what most people creating product listings or blog posts signed up for. Finally, "lossless versus lossy" is a genuinely technical distinction dressed up in marketing language like "compress without losing quality," which leaves non-experts unsure when a tiny, invisible quality loss is a fair trade for a much smaller file (it usually is, for photographs).

None of this is unknowable. It is just specialist knowledge that has nothing to do with running a shop, shooting a gallery, or writing a page. That gap, between what good optimisation requires and what a normal user can reasonably hold in their head, is exactly what an AI front end is built to close.

The 2026 format landscape, in plain terms

For most sites in 2026 the pragmatic answer is: serve AVIF first, fall back to WebP, and keep JPEG or PNG as a final safety net. That single rule captures almost all of the available savings while staying compatible with every browser in use.

Here is why. WebP is effectively universal across evergreen browsers, and web.dev reports it typically cuts file size by 25–35% versus JPEG and PNG at comparable quality. AVIF goes further again, usually shaving another meaningful chunk off WebP at the same visual quality, and Can I Use shows AVIF now supported across current Chrome, Edge, Firefox, and Safari and their mobile versions. That combination is why Google's own Lighthouse flags images that are not in a modern format: the savings are large and the support is there.

JPEG XL is the interesting outlier. It compresses superbly, but its browser support is split: Can I Use shows it enabled by default in Safari 17 and later, while Chrome and Edge keep it off by default and Firefox hides it behind a preference. Industry estimates put the share of browsers that can natively display JPEG XL at roughly 14 percent. That makes it excellent for archival, photography pipelines, and Apple-centric audiences, but not yet a safe default for general web delivery. The honest position is that JPEG XL is a "use it deliberately, not by default" format in 2026.

The practical takeaway is that you do not need to memorise any of this. You need a tool that knows the current support picture and applies it for you, generating the modern format with the right fallback rather than making you choose. We keep a live quality comparison tool so you can see the formats side by side on your own images, and our next-gen formats guide goes deeper on the trade-offs.

Why this is really a speed-and-revenue problem

Image weight is not a cosmetic concern; it is usually the single biggest lever on page speed, and page speed feeds directly into rankings and revenue. Images are consistently the heaviest resource type on a typical page, accounting for the largest share of transferred bytes according to the HTTP Archive Web Almanac. Cut that weight and you move the metric Google actually measures.

That metric is Largest Contentful Paint. Web.dev defines a "good" LCP as occurring within 2.5 seconds, and on most content-led and commercial pages the LCP element is an image, typically a hero shot or the main product photo. The arithmetic is unforgiving: on a typical mobile connection a 500 KB hero takes several times longer to arrive than a 100 KB optimised version, and that difference lands squarely on your LCP before the server or the browser has done anything else. Compress and resize that one image well and you can claw back a few hundred milliseconds on the most visible part of the page.

Those milliseconds have a price. Google Search Central confirms Core Web Vitals are used by its ranking systems, acting as a real tiebreaker between pages of similar relevance, which matters most on competitive commercial queries. And the commercial impact is measurable: Deloitte's "Milliseconds Make Millions" study, commissioned by Google, found that a 0.1 second improvement in mobile site speed was associated with an 8.4% lift in retail conversion rate and a 9.2% rise in average order value. Akamai's Image Manager case study with The Telegraph reported that reducing image weight by around 50% improved overall page load time by 9.6% and cut mobile load time by nearly a third.

This is the part worth sitting with. The edge here is not exotic. It is the same images everyone else has, shipped lighter and faster. A competitor relying on default export settings ships heavy pages; you ship light ones; over thousands of visits that compounds into better rankings, lower bounce, and more orders. Our hero image optimisation guide covers the LCP mechanics in more detail.

How AI image compression removes the guesswork (and how it differs from generative AI)

A natural-language interface for image work means you describe your goal in plain English and a language model maps it to precise operations, which a deterministic engine then executes. This is the opposite of generative AI. Nothing is being invented or hallucinated. The model is not drawing new pixels; it is choosing a format, a quality, and a size based on best practice, then handing the actual encoding to a native engine that produces the same output every time.

That distinction matters because the "AI image" space is crowded with tools that generate or detect synthetic pictures. This is neither. Instead of clicking through dropdowns for "convert to AVIF, resize to 1600px wide, quality 75, strip metadata," you type something like "make these product photos web-ready, under 120 KB each, and remove the location data," and the system resolves the parameters for you. Mochify calls this Magic Flow. Under the hood it is a two-step pipeline: a language model (currently Mistral Small 4) parses your prompt, then Mochify's native C++ engine does the compression. There is no quality slider to misjudge and no settings panel to learn. The plain-English description is the interface.

For a non-technical creator or seller, this collapses a stack of specialist decisions into one sentence about the result they want. Phrases that map cleanly to real intent work well: "compress these for Shopify listings," "convert to AVIF with a fallback and keep them sharp," "shrink this for an email newsletter." The model carries the knowledge of LCP, chroma subsampling, and AVIF tuning so you do not have to. And because the same prompt interface is available to developers and agents too, the knowledge gap closes for everyone at once rather than only for the people who already understand codecs.

One interface, every surface: from a single prompt to an agentic pipeline

The same natural-language approach runs everywhere you might want to work, which is what lets a casual user and a power user use one tool rather than two. It helps to separate two ideas the rest of this section relies on. Surfaces are where you reach Mochify: the web app, the Chrome extension, the command-line tool, the local MCP server, and the hosted MCP server. Formats are what it does to your files: images, PDFs, and video. They are different kinds of thing, so we keep them separate.

At the casual end, the web app and the Chrome extension are point-and-describe: drop in your files, type what you want, download the result. Images and PDFs are sent to Mochify's servers for encoding; video is the exception, processed entirely inside your browser so the footage never leaves your device.

At the power-user end, the same engine is a developer surface. The command-line tool (mochify, installed with brew install mochify) brings Magic Flow to your terminal with a -p flag, so a prompt fits straight into a build script:

mochify -p "convert to avif, max 1600px wide, keep them sharp" ./images

The REST API at api.mochify.app exposes the same capability through POST /v1/prompt for natural language, POST /v1/squish for direct image work, and POST /v1/pdf for document pages. Authentication is a one-time mochify auth login in the browser.

The surface that defines the category, though, is the MCP server. The Model Context Protocol is an open standard from Anthropic that lets AI assistants call external tools in a controlled, structured way, often described as a USB-C port for AI applications. Mochify ships two MCP surfaces. The local MCP server (mochify serve, the same binary as the CLI) returns file paths and metadata rather than image bytes, so the picture data never bloats the agent's context, which is the right default for developers building with Claude Code, Cursor, or Cline. The hosted MCP server at mcp.mochify.app needs no install and returns a short-lived download URL (valid for about five minutes) instead of inline binary, which suits non-developers who just want it to work. Both surfaces are available on every pricing tier, including Free; MCP and API access are not paywalled. Our guide to the hosted vs local MCP server walks through setup for each.

Bulk work without the busywork

The volume problem is where the spectrum pays off, because real catalogues and galleries generate far more images than anyone wants to drag through a browser one batch at a time. A product catalogue, a photographer's shoot, or a marketplace listing set can run to hundreds or thousands of files, and manual optimisation simply does not scale to those numbers; it gets skipped, and the site ships heavy.

Manual batching is fine for a handful of images. On the free tier you can process three files at a time, and on a paid tier up to 25 in a single batch, which covers most one-off jobs. Beyond that, the answer is to stop touching individual files. Wire the CLI into your upload step or build, and every new image is converted to AVIF with a WebP fallback, resized, and compressed automatically. Or let an AI agent do it: because the engine is exposed over MCP, an agent can scan a folder for oversized images, batch-convert them, and report back, all from one natural-language instruction. A non-technical colleague describes the policy once ("all new listings as AVIF and WebP, max 2000px"), a developer wires it in once, and after that it runs in the background. Our product photo workflow guide and the photographer automation guide show both patterns in practice.

The time saved is real even if it is hard to put a single number on: an afternoon of manual work per campaign becomes a process that runs itself.

Mochify Workflow: a web-ready product set in one prompt

Here is the end-to-end flow for the most common job, getting a set of product photos web-ready, led by Magic Flow.

How Mochify compares to the tools you already know

The established tools are good at what they do; the gap is in how you reach them and how much you need to know. TinyPNG now offers smart AVIF, WebP, PNG, and JPEG compression through a friendly web app plus a REST API and SDKs, which is a solid option for basics and for developers happy to script against an HTTP endpoint. Squoosh, Google's open-source app and CLI, exposes fine-grained, codec-level control (WebP, AVIF, JPEG XL, MozJPEG, and more) and is excellent for developers who want to turn every knob, though it runs as a local dev tool rather than a managed service. ILoveIMG provides pragmatic browser utilities and a general image API. ShortPixel pairs a cloud service with WordPress plugins and a CDN. Cloudinary is a full media platform with automatic format selection and a deep transformation API.

Two things stand out across all of them. First, modern-format support is converging on WebP and AVIF, but a true natural-language interface is not something any of the mainstream services currently offer; they expect you to operate dashboards, plugins, sliders, or API parameters yourself. Second, none of them ships a first-class MCP server for AI agents. That is the niche Mochify is built for: best-practice image and PDF engines reachable by plain-English prompt across the web, a browser extension, a CLI, two MCP surfaces, and a REST API. If your work is mostly manual and WebP is enough, the incumbents are perfectly good. If you want the settings decided for you, or you are building agentic workflows, that is where the difference shows. You can see the output quality for yourself on our comparison tool, and our European alternative to TinyPNG guide covers the privacy angle in detail.

Privacy, retention, and GDPR

If your images show identifiable people or carry metadata like GPS coordinates, they count as personal data under UK and EU GDPR, which means the tool you use to process them is a data processor and you are the controller. That makes retention and data transfer real compliance questions, not just nice-to-haves. Regulators including the UK ICO and the EDPB expect controllers to use only processors that provide sufficient guarantees, to hold clear contracts covering the nature and purpose of processing, and to understand where data is stored and whether it leaves the UK or EEA.

This is why Mochify's retention model is built the way it is, and why it is worth being precise rather than making a single blanket claim. Images and PDFs are streamed into server memory at api.mochify.app, encoded, and wiped immediately, with no disk writes of the source and no logs containing file data. The hosted MCP server additionally holds the compressed output behind an unguessable, five-minute download URL so an agent can fetch it, then evicts it; the original is still discarded at once. The local CLI and local MCP server skip that pickup step entirely and stay zero retention end to end. Video, as noted, never leaves your browser at all. The aggregate position is simple to state honestly: zero retention on image and PDF, and video never leaves the device.

Cheat sheet

Format decision, at a glance

Which surface

FAQ