Compress and Convert Images Without Uploading

Format selection changes file size more than any quality adjustment, and the decision rule is short.

WebP is the sensible default for photographs and most interface imagery on the web. It typically produces files 25–35% smaller than JPEG at visually equivalent quality, supports transparency, and is supported by every current browser. The one reason to avoid it is a consumer that cannot read it — some older email clients and desktop software still cannot.

AVIF compresses better still, often 20–30% below WebP, and is now widely supported. Its costs are real: encoding is markedly slower, and it can smooth fine texture in a way that matters for detailed photography.

JPEG remains the safest interchange format. If a file is going to a client, a printer or an unknown application, JPEG is understood everywhere.

PNG is for images that need lossless fidelity or transparency with sharp edges: logos, screenshots containing text, diagrams, icons. Saving a photograph as PNG is the single most common cause of unnecessarily large images — a PNG photograph is routinely five to ten times the size of an equivalent JPEG with no visible benefit.

SVG, where the source is vector, beats all of them. It is text, it scales to any size, and it is usually smaller than a raster at any resolution.

The rule, stated simply: photographs to WebP or JPEG, flat graphics with sharp edges to PNG or SVG. Getting this wrong costs more than any amount of slider adjustment can recover.

File size scales with pixel count, and pixel count scales with the square of the dimensions. Halving an image's width and height leaves a quarter of the pixels.

This is why resizing is the highest-leverage step and why quality adjustment alone rarely fixes an oversized image. A 4000×3000 photograph from a phone camera displayed in a 800-pixel-wide column contains 15 times more pixels than the layout can show. Re-encoding it at lower quality reduces the file somewhat; resizing it to 1600 pixels reduces it by roughly 94% before quality is touched at all.

Practical target widths:

• Full-width hero images: 1920px, or 2560px if you need to serve high-density displays a single file.
• Content images in a text column: 1200–1600px.
• Thumbnails and avatars: 2× their display size, no more.

The 2× figure is the concession to high-density screens. A display with a device pixel ratio of 2 renders a 400px-wide element using 800 physical pixels, so an 800px source is sharp. Beyond 2× the returns are imperceptible and the bytes are wasted — a 3× image is 2.25 times the size of a 2× image for a difference almost nobody can see.

Where you can serve multiple files, srcset lets the browser choose by viewport and density, which is better than any single compromise:

<img src="photo-800.webp"
     srcset="photo-800.webp 800w, photo-1600.webp 1600w"
     sizes="(max-width: 700px) 100vw, 700px"
     alt="">

The quality slider in a JPEG or WebP encoder does not set a percentage of visual fidelity. It scales the quantisation table — how aggressively the encoder discards high-frequency detail after the discrete cosine transform.

That is why the relationship between the number and the result is so non-linear, and why the useful range is narrower than the 0–100 scale suggests:

• 90–100: Very large files for a difference almost nobody can perceive. Worth it only for images that will be edited further, since each re-encode compounds loss.
• 75–85: The practical range for web photography. 82 is a defensible default. Artefacts are essentially invisible at normal viewing distance.
• 60–75: Visible softening in detailed areas, acceptable for thumbnails and backgrounds.
• Below 60: Blocking and ringing become obvious, particularly around text and sharp edges.

Two properties of the image change where in that range you should sit. Fine texture — foliage, fabric, crowds, hair — carries high-frequency detail that quantisation destroys first, so such images need a higher setting. Flat areas with sharp boundaries — text in a screenshot, a logo on a plain field — produce ringing artefacts at any JPEG setting, which is the signal that the file should have been PNG.

Re-encoding is not free. Every JPEG save discards information permanently; opening a JPEG, making a small edit and saving repeatedly degrades it visibly over a handful of cycles. Keep an original and export from it.

A photograph from a phone or camera carries an EXIF block, and people are routinely unaware of what is in it:

• GPS coordinates of where the photograph was taken, often to a few metres.
• Date and time, including the device's timezone.
• Camera make, model and serial number, which links photographs taken by the same device across contexts.
• Lens, exposure settings, and frequently an embedded thumbnail — which, notoriously, is not always regenerated after cropping, so the original uncropped image can survive inside the file.

Uploading a personal photograph with GPS intact discloses a home address. It has been the mechanism behind a long list of accidental disclosures.

EXIF also affects rendering. The Orientation tag tells a viewer to rotate the image, and software that ignores it displays photographs sideways. When an editing pipeline strips metadata without first applying the rotation, correctly-stored images start appearing rotated — one of the more confusing image bugs to diagnose.

Not all metadata should be stripped indiscriminately. Colour profiles matter: removing an embedded ICC profile from an image in a wide-gamut space such as Display P3 causes a browser to interpret the values as sRGB, producing visibly dull or oversaturated colour. Copyright and author fields are worth keeping for published work.

The defensible default is: strip GPS, device serial and timestamps; apply and then normalise orientation; keep the colour profile.

Image optimisation is arithmetic over a pixel buffer. <canvas> decodes, resizes and re-encodes; createImageBitmap handles large files without blocking the main thread; every current browser ships WebP encoding and most now ship AVIF. There is no step that requires a server.

That matters more here than for most file types, because of what people optimise. Photographs of people, identity documents being shrunk to meet a portal's upload limit, unreleased product shots, medical images, screenshots containing customer data. An online optimiser that uploads the file has received the full-resolution original with its metadata intact — before any stripping the tool advertises has taken place.

The OpenTools image optimizer resizes and re-encodes in the page. The practical consequences are worth knowing: there is no upload wait, batch size is bounded by your device's memory rather than a service quota, and very large images are limited by the browser's canvas dimensions rather than by a plan tier.

A short checklist that covers most cases:

1. Resize to the largest size actually displayed, times two for high-density screens.
2. Choose the format by content type, not habit.
3. Set quality around 82 for photographs, higher for fine texture.
4. Strip location and device metadata, keep the colour profile.
5. Keep the original. Every lossy export is one-way.