Security at Compress Images

Where your file goes

When you drop or choose a file on the home page, your browser reads it and converts it in a Web Worker on your own device. Nothing is copied into this site’s storage: the tool writes no IndexedDB, no Cache Storage and no cookies, and the file is not sent to us. The privacy policy is the one place that is said in full, including what the hosting provider sees when you load a page.

No upload does not mean no network. Loading the tool page makes the browser ask this site for that page’s HTML, its stylesheet and the JavaScript modules that drive the tool. Starting a run adds the worker script and the codec modules that run needs, each fetched once from this site: the input format’s decoder, the output format’s encoder, and the resize or PNG optimiser modules when the run uses them. The first run in a given format is the one that fetches it. A page that is not the tool loads only its own HTML, stylesheet and modules, and no codec at all. All of that is this site’s own address and nothing else: every request a page makes, before a run, during a run and after it, is a GET or a HEAD with no body, and no request carries your file.

Once a module has been fetched, the same conversion runs again with the network switched off, which is the check behind that sentence. None of it depends on trusting a promise: you can compress an image without uploading it and watch your own network tab while it happens.

The Content-Security-Policy

Every page is served with a Content-Security-Policy that lets scripts load only from this site and connect only to this site: connect-src 'self' blob:. The blob: is not another origin. It is the scheme of the object URLs this page creates for your own before-and-after previews and download links, and a browser resolves such a URL inside the origin that created it. That is wider than “only this page can read it”: the URL is scoped to the creating origin and to the storage partition the site sits in, which is the browser’s own storage partitioning, so the restriction comes with a partitioning rule this site does not control and has not measured. What the policy does establish is that a script has no address to reach beyond this site: if one tried to fetch from or post to some other origin, the browser would block the connection before it left.

What the file you get back carries

By default the output carries no EXIF at all: no EXIF segment in a JPEG, no EXIF chunk in a WebP, and no metadata item in an AVIF or a PNG. Camera, location and timestamp data therefore do not travel with the picture you download, which is usually what you want from a copy that has been encoded again.

The keep control changes that, with one limit. Tick “Keep EXIF metadata” and the block comes back in a JPEG, PNG or WebP output, with the orientation written as 1 because the pixels have already been turned the right way up. An AVIF output cannot carry an EXIF block here, so with AVIF selected the control has no effect and the row says the metadata was not kept.

Either way, the orientation your camera stored is applied to the pixels, so a photo taken in portrait comes out the right way up. That applies to a JPEG, a PNG or a WebP input. An AVIF input is the exception: its EXIF block is not read, so an AVIF file that stores a rotation is used as it is stored. Of the eight EXIF orientations, the four that include a quarter turn, 5 to 8, also swap the width and the height with it, so a photo tagged 6 comes out 400 by 600 from a file whose numbers read 600 by 400. The 180 degree turn is not one of those four: it turns the picture without changing either number.

What the tool cannot give back

The output is the picture you chose, decoded, optionally resized, and encoded again in the format you selected, at 8 bits per channel in the sRGB colour space browsers work in. PNG, WebP and AVIF keep transparency; a JPEG output has no alpha channel, so what was transparent is flattened onto white. A JPEG output is also written progressively with its colour channels subsampled, which is MozJPEG’s own default and not a setting this tool exposes.

Lossy compression discards detail, and the tool does not restore anything it did not receive. A smaller file is not automatically a better one, which is why every finished row shows both sizes and both pictures side by side.

Reporting a security problem

If you find a security problem, write to security@compress-images.online. The site’s security.txt file lists the same address. A problem in the tool itself is worth reporting the same way, and the format you selected and the settings you used are the two things that help most.