Image Converter

Choosing between the three formats

PNG is lossless. Every pixel comes back exactly as it went in, it supports full alpha transparency, and it compresses flat areas of colour extremely well. That makes it right for screenshots, diagrams, logos, line art, anything containing text, and anything needing transparency. It is a poor choice for photographs, where lossless compression finds little to remove and files come out several times larger than they need to be.

JPG is lossy and built for photographs. It discards detail the eye is bad at noticing, particularly fine colour variation, and achieves large reductions on continuous-tone images. It has no transparency at all, and it handles hard edges badly - text and line art in a JPG acquire visible fringing that no quality setting removes entirely.

WebP does both. Lossy WebP typically lands 25-35% smaller than JPG at comparable quality, lossless WebP beats PNG by around a quarter, and unlike JPG it supports transparency. Browser support is universal now, and the main remaining reason to prefer JPG is that some older desktop software and print workflows still do not accept WebP.

What the quality slider does

JPG and lossy WebP work by transforming the image in blocks, then quantising the result - keeping the coarse structure precisely and the fine detail approximately. The quality number controls how aggressively that rounding happens. It is not a percentage of anything, and the same number means different things in different encoders.

In practice the useful range is narrow. Above about 90 the file grows quickly for differences almost nobody can see. Below about 60 the artefacts become obvious: blocking in smooth gradients like skies, and ringing around hard edges. Somewhere between 75 and 85 is the usual sweet spot for photographs on the web, and the right way to choose is to compare the output against the original at full size rather than trust the number.

The other thing to know is generation loss. Every lossy re-encode discards a little more, and the loss compounds - a JPG opened, edited slightly and saved ten times is visibly degraded. Always re-encode from the original rather than from a previous export, and keep a lossless master if the image will be revised.

What re-encoding leaves behind

The conversion decodes the image to pixels and writes a new file from those pixels, so everything that was metadata rather than image data is dropped: EXIF, including camera model, lens, timestamp and GPS coordinates; IPTC captions and copyright fields; thumbnails; and any editing history the originating software attached.

That is usually welcome. A photo straight off a phone typically carries the exact coordinates of where it was taken, and stripping it before posting publicly is a sensible reflex. It is unwelcome if you needed the copyright field or the capture date, so keep the original if either matters.

One case needs care. The orientation flag is read and applied before re-encoding, so a portrait photo that some viewers showed sideways comes out genuinely upright. But an embedded ICC colour profile does not survive, and a photo in a wide-gamut space such as Display P3 will shift slightly when it is treated as sRGB. For ordinary web images this is invisible; for colour-critical work, convert with a tool that manages profiles.

What conversion cannot do

Converting to a lossless format does not restore anything. A JPG saved as PNG keeps every artefact the JPG already had and simply stores them without further loss, in a much larger file. If an image has been through heavy compression, that damage is in the pixels now.

Nor does changing format reduce dimensions. A 4000-pixel photograph converted to WebP is still 4000 pixels wide; if the goal is a smaller file for a web page, resizing it to the size it will actually be displayed at saves far more than any format choice. The two operations pair well - resize first, then encode - and the resizer is the other half of that job.

What JPEG actually throws away

JPEG works in blocks of eight by eight pixels. Each block is transformed by a discrete cosine transform into a set of frequency coefficients - one describing the average tone, the rest describing progressively finer detail - and those coefficients are then divided by a quantisation table and rounded. The high-frequency ones usually round to zero, and zeros compress extremely well. That rounding is the loss.

Before any of that, the image is converted from RGB into a luminance channel and two colour channels, and the colour channels are usually stored at half resolution in each direction. This is chroma subsampling, written 4:2:0, and it exploits the fact that human vision resolves brightness detail far better than colour detail.

Both steps explain the artefacts. Blocking in a smooth sky is the eight-by-eight grid becoming visible when too many coefficients round to zero. Coloured fringing around red text on a white background is chroma subsampling: the edge is sharp in luminance and blurred in colour. No quality setting removes the fringing entirely, which is why text belongs in PNG or WebP.

The formats beyond these three

AVIF, derived from the AV1 video codec, compresses substantially better than WebP at low and medium quality, supports wide colour and transparency, and is now supported by every current browser. It is slower to encode, and very low-quality AVIF smooths detail into a waxy texture rather than showing blocks, which some people find worse than the equivalent JPEG.

HEIC is what modern iPhones produce by default. It is efficient but patent-encumbered and unsupported in browsers, so images taken on a phone frequently need converting before they can go on a website. SVG is not a raster format at all: it is markup describing shapes, which makes it ideal for logos and icons at any size and useless for photographs.

GIF persists for one reason, inertia. It has 256 colours, no alpha channel worth the name, and produces files several times larger than the equivalent video for an animation. An MP4 or WebM does the same job at a fraction of the size.

Serving images on a page

Format choice matters less than serving the right dimensions. A 4000-pixel photograph displayed in a 600-pixel column wastes most of its bytes regardless of codec. The srcset attribute lets the browser choose from several widths, and sizes tells it how wide the image will actually be rendered, which together usually save more than any re-encoding.

The picture element goes further by offering different formats, so a browser takes AVIF if it can, WebP if not, and JPEG as the floor. Serving that permutation by hand is tedious; an image CDN or a framework's image component generates it.

Two attributes are worth setting on every image: explicit width and height, so the browser reserves the space and the page does not shift as images load, and loading=lazy on anything below the fold. The image that is visible first should not be lazy, since delaying it directly worsens the largest contentful paint.

Colour profiles, transparency and print

An ICC profile tells a viewer how to interpret the numbers in a file. A photo from a modern phone is often tagged Display P3, and when that tag is lost the same numbers are read as sRGB, which shifts every saturated colour. This conversion decodes to pixels and writes a fresh file, so the profile does not survive - fine for ordinary web images, not fine for colour-critical work.

Transparency has a similar gap. Converting a PNG with an alpha channel to JPEG composites it against a background, and the usual result is a black or white halo around anti-aliased edges. WebP and AVIF keep the channel, so they are the right target when transparency matters.

Print is a different pipeline. Screens are additive RGB and presses are subtractive CMYK, the conversion depends on the ink, paper and press profile, and vivid screen colours frequently have no printable equivalent. Any CMYK value shown in a browser tool is an approximation, useful for a rough idea and not for a proof.

Metadata, privacy and provenance

A photograph carries far more than pixels. EXIF records the camera and lens, the exposure settings, the date and time, and often the GPS coordinates where it was taken. Social platforms generally strip this on upload, but files sent by email, attached to a ticket or uploaded to your own site usually keep it.

Stripping metadata is the default behaviour of any re-encode, including this one, which is the privacy-friendly outcome most of the time and an annoyance when the copyright, caption or capture date mattered. If any of those are part of the record, keep the original and treat the converted copy as a derivative.

One field is worth preserving deliberately: orientation. Cameras store rotation as a flag rather than rotating the pixels, so a portrait photo can appear sideways in software that ignores it. Applying the rotation before re-encoding, as happens here, is what makes the converted file display correctly everywhere.