What an Image File Format Actually Is

A format is a storage contract

Take a 1920 x 1080 picture. That is 2,073,600 pixels, and a normal color pixel needs three numbers (red, green, blue) of one byte each. Stored with no cleverness at all, the picture takes 2,073,600 x 3 = 6,220,800 bytes, about 6.2 MB. Every common image format is a different answer to the same question: how do we get that number down, and what do we give up to do it?

A format therefore has two layers. The container is the wrapper: a signature that says what kind of file this is, the width and height, optional extras such as a color profile or camera data. The codec is the method that packs the pixel values themselves. JPEG, PNG and WebP each bundle a container with one or more codecs, which is why WebP, for instance, may hold lossy or lossless data, chosen when the file is saved.

What the first bytes of a file reveal

The extension at the end of a file name (.jpg, .png) is only a label. The real identity sits in the first few bytes. I generated one test picture and saved it in five formats with Pillow, then printed the opening bytes of each:

JPEG  ff d8 ff e0 00 10 4a 46 49 46     (JFIF marker)
PNG   89 50 4e 47 0d 0a 1a 0a           (the text "PNG" after a high byte)
GIF   47 49 46 38 37 61                 (the text "GIF87a")
BMP   42 4d 36 ec 5e 00                 (the text "BM")
WebP  52 49 46 46 .. .. .. .. 57 45 42 50   ("RIFF", a length, then "WEBP")

Programs read these signatures to decide which decoder to use. That is why a PNG renamed to .jpg often still opens on your own computer but gets refused by an upload form that checks the content, and why renaming never makes a file smaller or more compatible. The bytes have to be rewritten by an encoder, which is what conversion is.

The BMP line also shows how plain a container can be. My 1920 x 1080 BMP was exactly 6,220,854 bytes: the 6,220,800 bytes of pixels plus a 54-byte header. Nothing else, no compression at all.

Six formats compared by what they are built for

The table lists the formats you will meet most often. It describes what each can do, not which one is best, because that depends on the picture.

Format	Compression	Transparency	Animation	Built for
JPEG	Lossy	No	No	Photographs
PNG	Lossless	Yes, partial	Not in the base format (APNG is an extension)	Screenshots, logos, graphics with text
WebP	Lossy or lossless	Yes	Yes	Web delivery of photos and graphics
GIF	Lossless, 256 colors per frame	On or off only	Yes	Short looping clips, tiny graphics
AVIF	Lossy or lossless	Yes	Yes	Smallest files where browsers support it
SVG	Not pixels at all (text description of shapes)	Yes	Possible, rarely used	Logos, icons, diagrams

BMP is the one missing from the table because it has no special strength: uncompressed pixels, large files, mostly found in old software and scans.

Raster or vector: the split that comes before everything else

JPEG, PNG, WebP, GIF, AVIF and BMP are raster formats: they store a grid of pixels, so they have a fixed size and look soft or blocky when enlarged. SVG is a vector format: it stores instructions such as "a circle of radius 40 at this position, filled with this color". A simple logo can be a few hundred bytes of text and stays sharp at any size, from a favicon to a billboard.

The catch is that vectors only suit drawn shapes. A photograph has no circles to describe, so it must be raster. And before an SVG can be used somewhere that only accepts pictures made of pixels, it has to be drawn at a chosen size, which is the job covered in converting SVG to PNG or JPG.

Three questions that pick the format

1. Is it a photograph or a drawing? Photos have smooth, noisy gradients where a lossy format saves a lot and the damage hides in the detail. Drawings, screenshots and text have hard edges and few colors, where a lossless format is both exact and often small.
2. Does any part need to be see-through? If yes, JPEG and BMP are out, because they cannot store transparency. PNG, WebP, AVIF and SVG can.
3. Where will it be opened? The newest format is useless if the destination cannot read it. JPEG and PNG open essentially everywhere; WebP is now supported by current versions of all major browsers (Safari from version 14, in 2020); HEIC, the iPhone default, is the format most likely to fail outside Apple devices.

Questions one and two are worked through with real numbers in JPEG vs PNG.

Same pixels, very different file sizes

To show why the choice matters, I made two synthetic 1920 x 1080 test pictures. Picture A has flat color blocks and lines of text, like a screenshot. Picture B has smooth color gradients and blurred shapes with fine noise added, a rough stand-in for a photo. Real files vary, so read these as an illustration of the pattern, not as typical results.

• Picture A: PNG 135,263 bytes; JPEG at quality 90 219,783 bytes; lossy WebP at quality 90 89,924 bytes.
• Picture B: PNG 3,587,826 bytes; JPEG at quality 90 330,904 bytes; lossy WebP at quality 90 323,786 bytes.

Both pictures contain the same 6,220,800 bytes of raw pixel data. The flat picture shrinks 46-fold in PNG because large uniform areas are easy to describe exactly. The noisy one shrinks less than two-fold in PNG, because noise cannot be predicted, but about nineteen-fold in JPEG, which is allowed to smooth it. Opposite winners from the same pair of formats is a large part of why formats exist side by side. The mechanics behind those numbers are in lossy vs lossless.

When converting is the right move

Convert when the destination demands something the current format cannot give: a format it can open (HEIC photos to JPG for a form that rejects them), a smaller file for email, or transparency for a web graphic. Do not convert hoping to improve the picture. A format change cannot restore detail an earlier save discarded, and the extent of what survives is covered in image quality after converting.

On this site the converter's outputs are JPEG, PNG, WebP, BMP and ICO; there is no AVIF, GIF, HEIC, TIFF or PDF output, so those formats need other software. HEIC files can be added as input only where the browser itself can decode them, in practice Safari on Apple devices.