Image formats: raster, vector, transparency and what really belongs on the web

When we ask a client for their logo, we get it three times on average. First as a JPG cut out of the old website, then as a photo of a business card, and only on the third attempt as a file we can actually work with. Nobody is to blame for that: there are some twenty image extensions these days and nowhere does it say which one is for what. So we will write it out here, starting from the one distinction that really matters.

Raster and vector: the one distinction that really matters

A raster image is a grid of pixels. The file inside says: the pixel at position 418, 203 has this colour. And then it says the same thing a million more times. The size is baked into it, so when you enlarge it, something has to invent pixels that were never measured, and the result is a smear.

A vector image is a set of instructions. From this point draw a curve to here, close it and fill it with this colour. Nowhere does it say how big it is, because the device works that out at the moment of drawing. That is why it is sharp at sixteen pixels and on a billboard.

It shows best on our own logo. The MeaOvis mark at the top left of this page is four curves. In the HTML it is 596 bytes of SVG written straight into the page, so the browser does not even request it separately. The same markup serves the thirty six pixels in the menu and any other size.

For comparison, we rendered the same mark into PNG with a transparent background:

PNG grows with the square of the size, SVG does not grow at all. At a thousand pixels the raster version is twenty three times bigger and still goes soft on the next larger screen. That is the whole difference, in one table.

And now the less pleasant half: vector does not work for a photograph. A vector format describes shapes, but a photograph contains no shapes. It is the measured intensity of light at a million points. Nobody is going to draw your reception desk with curves, and if anyone tried, the file would end up bigger than the photo and it would look like a poster.

That gives a simple rule. Whatever is drawn belongs in vector. Whatever is photographed belongs in raster. Most of the mistakes we see happen because a drawing ended up in raster.

Transparency, or why a logo in JPG will not help you

JPG has no alpha channel. Not that it handles one badly, it simply does not have one. Every JPG is a full rectangle, and where the logo “has nothing”, JPG has white. Put it on a dark background and you get a white box around the logo. This is the most common reason a logo looks wrong on a website, and nothing other than a different file will fix it.

PNG does have an alpha channel: eight bits per pixel, which is 256 levels of transparency. That is enough for soft edges and for shadows.

So that eternal question, “JPG or PNG”, is really two questions. Is it a photograph, or a drawing? And does it need a transparent background? For a photograph you take the JPG family, for a drawing PNG, and when transparency is needed, PNG without discussion.

There is a third thing that gets forgotten. JPG is lossy, PNG is not. Every time a JPG is opened and saved it loses a little more. Save a logo through JPG three times and the edges already have grey fringes. PNG gives back exactly the pixels you put into it.

Being lossless is paid for in size. We measured it on a real photo from our own website, 1200 × 801 pixels, from the project for Optik Petrík:

The exact commands are in the technical appendix at the bottom, so that anyone can repeat it. The numbers depend on the photo: a wall compresses differently from foliage. The order stays the same.

Notice that difference between JPG and WebP. It is a quarter of the size on the same photo and with no visible difference. On a mobile connection that is exactly the difference between a page that loads and a page people leave before they ever see it.

Formats that belong on the web

SVG is text, and that has its downside too

An SVG can be opened in a text editor and read. All of its advantages come from that: you change its colour in CSS, it can be written straight into the page with no extra request, and it compresses together with the page.

But for that same reason an SVG can contain a script. A file with an image extension that can run code in a visitor’s browser is not an image, it is a program. That is why we never pass on an SVG uploaded by a stranger the way it arrived. In forms where people upload files we either do not accept it, or we clean it first. It is a small thing that even large websites run into.

WebP or AVIF

Both have transparency, both handle animation and both carry metadata just as well as JPG. AVIF is smaller, but it encodes more slowly and its support is newer, even if it too is now above ninety percent.

For now we send WebP. One file, no fallback, no two variants of every image. At the page sizes we build, those few extra kilobytes would not be worth paying for with twice as many files to manage. On an online store with a thousand products the arithmetic is the other way round, and there AVIF with a WebP fallback does make sense.

To be complete: the images for sharing, the ones that show up when somebody drops a link to our website into a message, we leave in JPG. They are read by the networks, not by browsers, and those networks need not handle the modern formats.

GIF no longer has a reason to exist

GIF has 256 colours per frame and a compression scheme designed in 1987. The same photo we measured above takes 271 kB as a GIF and looks noticeably worse than the 86 kB in WebP, because its colours have to be rounded down to two hundred and fifty six.

With animations it is starker still. A recorded application window can easily take ten times as much as a GIF as it would as video. When you do still see a GIF somewhere, it is usually because the platform will not take anything else.

ICO is not a format, it is an envelope

ICO is a container holding several raster sizes at once. In our own favicon.ico there are three of them: 48 × 48, 32 × 32 and 16 × 16, all of them 32-bit, 15,086 B in total. The same mark as favicon.svg is 2,654 B and works at any size.

We keep both. Older browsers do not know an SVG favicon, and they request /favicon.ico even when nothing links to it.

JPEG XL: the interesting one you cannot bet on yet

Technically it is the best of the whole list. It is smaller than AVIF at the same quality, it handles progressive loading, and it can do something nothing else can: it recompresses an existing JPG losslessly and can produce exactly the same original file back out of it. An archive of old photos shrinks that way without anything in the pictures changing.

It is switched on in Chrome from version 155 and in Firefox from version 158, the ones reaching people right now. Safari has had it partially since version 17. Edge does not have it. Overall support is around sixty percent.

That is one to watch, not one to build on. Sixty percent means four people in ten would see no image at all, so a second file would have to exist anyway. When Edge joins in, we will do the arithmetic again.

Formats that do not belong on the web, and that we get anyway

It helps to sort them by what they are actually for. There are three groups and they get mixed up constantly.

• Working files. PSD, AI, Affinity. Layers, masks, edit history. It is not an image, it is a project, and it belongs with the designer.
• Exchange and print files. PDF, EPS, TIFF. For the print shop, the sign maker, the embroiderer.
• Delivery files. SVG, WebP, AVIF, JPG, PNG. For the visitor.

Only that third group goes on the web. Here is the rest, and why:

With HEIC it is worth adding why that is. It is not browsers being careless: HEIC has the HEVC codec inside and that codec comes with a complicated patent bundle. That is exactly why we had to deal with it separately for MeaReal and MeaCara. Somebody photographing a flat with a phone has no reason to know what a codec is, and should not find out from an error message. There is a detailed account of it in the article What your photos reveal about you.

What to send us when we ask you for your logo

This part is here because we end up saying it again on every project.

1. Vector ideally. SVG, AI or EPS. Out of a vector we make every size, the favicon, print and embroidery, and it never falls apart.
2. If all you have is raster, send the largest PNG with a transparent background that exists. Not a JPG downloaded from your own website, not a screenshot and not a photo of a business card. There is nothing to salvage from those three.
3. If you have nothing, say so straight away. Redrawing a logo from a four hundred pixel JPG into vector is an hour or two of work. That is cheaper than finding out three months later that the sign maker for your shop front has nothing to work from.

With photos it is simple, on the other hand: send the originals from the camera or the phone, as large as possible and unedited. We will take care of the resizing and the format. A photo you have already shrunk down for Facebook cannot be enlarged back.

In closing

If you take one sentence away from this article, let it be this one: whatever is drawn belongs in vector, whatever is photographed belongs in raster, and a working file never goes on the web.

And if you want to know what your own website serves as images and how much that weighs, it is listed by the free website audit without you having to hunt through extensions by hand.

Technical appendix

Here is what would otherwise slow the article down, but without which those numbers cannot be checked.

How we measured

The source was one photo from this website, 1200 × 801 pixels, converted to PNG. All the other files were made out of that same PNG:

sips -s format jpeg -s formatOptions 80 orig.png --out a.jpg
sips -s format heic -s formatOptions 80 orig.png --out a.heic
cwebp -q 80 orig.png -o a.webp
avifenc -q 60 --speed 4 orig.png a.avif

Two notes on how honest those numbers are. The numeric quality scales are not comparable between formats, which is why AVIF is listed at 60 and not 80; the settings are spelled out precisely so it is visible what is being compared with what. And the source photo had already been through lossy compression once, so the lossless PNG is somewhat larger than it would be from a camera original. That changes neither the order of the formats nor the orders of magnitude.

The PNG sizes for the logo were produced by rendering favicon.svg to the given size, so out of that same vector.

What an alpha channel is, and why eight bits

Every pixel has three numbers: how much red, green and blue there is in it. Alpha is a fourth number and it says how present that pixel is at all. Zero is fully transparent, 255 fully opaque.

Eight bits give 256 levels, and that is enough for a soft transition and for a shadow. PNG also has a cheaper form, a palette with one transparent colour, where a pixel either is or is not and nothing exists in between. That is where the jagged edges of old PNGs come from.

GIF has only that cheaper form, which is one single bit of transparency. That is exactly why an animated GIF on a coloured background has a light outline around it.

Why transparency does not exist in JPG

JPEG was created in 1992 for photographs and its construction reflects that exactly. It splits the image into a brightness component and two colour ones, throws away part of the colour detail because the eye does not see it, and compresses the rest in blocks of eight by eight pixels.

In that construction there is nowhere to write down that a pixel is not there. It is not a feature left out, but a consequence of what the format was designed for. That same discarding of colour detail is why a thin red line on a white background looks dirty in JPG.

A container, a codec and an extension are not the same thing

This distinction explains most of the confusion around the modern formats. The container is the envelope, the codec is the way the image data inside it is compressed, and the extension tells you about the envelope, not about the contents.

• HEIC is the HEIF container with the HEVC codec inside.
• AVIF is the same family of container with the AV1 codec.
• WebP is the RIFF container with the VP8 codec in the lossy variant and VP8L in the lossless one.
• AI has PDF inside, not some Adobe vector of its own.

The practical consequence: two files with the same extension can behave differently, and the extension on its own is not enough to decide whether a browser will display it.

Extensions that get confused

How an image is offered with a fallback

When you want to send a modern format and have a fallback for browsers that do not know it, that is done with the picture element. The browser takes the first source it understands and skips the rest:

<picture>
  <source srcset="/img/reception.avif" type="image/avif">
  <source srcset="/img/reception.webp" type="image/webp">
  <img src="/img/reception.jpg" alt="Shop reception"
       width="1200" height="801" loading="lazy" decoding="async">
</picture>

We do not use it on this website and it is only right to say why. We send one WebP, because at just under fifty pages in each language and just under thirty images, three files per image would cost us more work and more places to go wrong than the kilobytes it would save. On an online store the arithmetic turns around, and there three variants per image do make sense.

The attributes width="1200" height="801" should always be there, even when you stretch the image to a different size in CSS. The browser reserves the space in advance from them, so the page does not jump under the reader when the image arrives.

And one thing that happens to us as well

While writing this article we went through our own image folder and found sms-api.af: an Affinity working file of 1.1 MB that has no business being there. It never made it onto the server, because the deployment does not pick it up, so nothing came of it.

But it is exactly the mistake this whole article is about, and it happens to people who know better. Working files should have a folder of their own, outside whatever goes on the web.

Related reading

Everything that is written into a photo besides the picture: What your photos reveal: location, how fast you were moving, even the device serial number.

Why image sizes matter so much: Core Web Vitals in plain language: LCP, INP and CLS.

And if you want to know where your website stands right now: Free website audit.