SVG, PNG, WebP: how the wrong export format breaks the site

The logo on the landing weighs 800 KB and is washed on the retin. The icon of the social network in the footer is JPG with a white rectangle around. Photo of the hero - PNG at 4 MB, because "so exported designer." Screenshot of the interface in the blog - WebP, which does not open in the preview of the mail.

These are not fictional cases. This is what is on the review of almost every second site that comes to us. And almost always, the problem is not the design or the taste — the problem is that someone once clicked “Export as...” and didn’t think about what they were exporting or where they were going.

The export format is not a technical nuance for dessert. This is a solution that determines how fast a page loads, how it looks on different screens, how search sees it, and how much money goes to a CDN. An error in the format does not ruin the entire site – it slowly strangles it.

---

## Why is it even important

Images are 60-70% of the weight of the average website. Not scripts, not fonts, not CSS. Pictures. And if there are 40 images on the site, and each one weighs an extra 200 KB due to the wrong format, this is 8 MB, which the user downloads needlessly.

It's invisible on office WiFi. On the mobile Internet in the subway is the difference between “working” and “closed tab”.

Then the effect is cascading:

• Lighthouse and Core Web Vitals Fall as LCP Grows
• Search this sees and ranks the site below
• CDN bill increases in proportion to excess weight
• On weak devices, the page begins to twitch when scrolling, because the browser tries to decode huge rasters

The icon was saved as PNG instead of SVG, and the photo as PNG instead of WebP.

---

## Three formats, three tasks

If you simplify it to a level where you can use it every day:

• SVG - for everything that is drawn: logos, icons, illustrations, graphics.
• WebP (or AVIF) - for everything that is taken: photos, screenshots with photorealistic content, hero banners.
• PNG - for rare cases when you need raster graphics with transparency and WebP for some reason is not suitable (old mail, export to a third-party system, preview for social networks).

JPG is almost not needed in this scheme. It stayed as a compatible default, but WebP does the same thing better at the same quality.

Sounds simple. In practice, 80% of problems are a violation of this basic layout.

### Anti-pattern: "PNG for everything"

The most common scenario. The designer exports everything from Figma to PNG because it is a default and always works. Finally:

• Logo weighs 400 KB instead of 4 KB
• The logo is washed because it was exported in 1x
• Photo of the hero 3 MB PNG instead of 250 KB WebP
• Icons in the interface – separate PNG files instead of a single SVG sprite or icon font

It’s not about “re-exporting everything.” It is treated by agreement at the stage of transfer: what should be.

### Anti-pattern: "SVG for photo"

Less often, but it does. Someone has heard that SVG is “loss-free” and tries to stick a traced photo or a screenshot converted to base64 inside SVG. The file is 5-10 times heavier than WebP, renders slowly, and magnification shows trace artifacts.

SVG for vectors. If an object has shadows, gradients with complex transitions, textures are no longer a vector, and SVG will play the raster.

---

## Scenario: icons in the interface

The most common place where the format breaks down. Let's take it step by step.

Bad:

• Each icon is a separate PNG in 2-3 sizes (1x, 2x, 3x)
• The color of the icon is sewn into a file – to repaint, you need to make a new export
• When hover changes not the color, but the whole picture

Good:

• Icons – SVG, either in-line in HTML or via <use> from a sprite
• Color is controlled through currentColor or CSS variables
• Hover is the change of color or fill into one CSS class

The difference in weight is fine. The difference in flexibility is incomparable. And at the same time, the SVG icon scales to any size without blure.

Questions for the review of the icon set:

• All icons in one format (SVG)?
• Is the color controlled through CSS rather than stitched into a file?
• Are the sizes and proportions agreed between the icons?
• No extra <defs>, Figma metadata, comments in SVG code?
• Are icons optimized through SVGO or analog?

The last point is a separate pain. Raw SVG from Figma can weigh 3-5 times more than the same SVG after running through the optimizer. This is a free acceleration, which for some reason not everyone does.

## Screenplay: photo and hero banners

That's another story. The icon can be accidentally saved to SVG and not lost much. But the hero banner exported to PNG is almost always a few extra megabytes on the first screen.

Bad:

• Hero – PNG 2880×1620, because it is necessary for retina
• One file for all screen sizes
• No srcset and sizes, the browser pulls the full version even on the phone

Good:

• WebP (or AVIF + WebP as fallback) in multiple sizes
• <picture> with source for different widths
• loading="lazy" for anything below the first screen
• width and height are inserted so that there are no leyout shifts

The designer does not have to write <picture>. But I have to give the developer the source in the right format and in several sizes - not one giant PNG "you will figure it out there yourself.".

### Mini-checklist for hero-picture

• Source: WebP or AVIF, not PNG
• There are versions for mobile, tablet, desktop
• The size of each version is about tens, not hundreds of KB
• If the picture is text - it is not sewn into a raster, but lies in a separate layer of HTML
• The image does not block LCP – that is, it is given priority, not lazily

---

## Workflow: agreements are more important than settings

The main mistake is to think that the issue of export is solved by the “correct settings in Figma”. He doesn't. Resolved by agreement at team level.

### What to fix in the product guidelines

• What format for what type of asset (one line, without "depends on the case")
• What are the maximum file sizes considered acceptable
• Where icons lie and how they connect (sprite, online, component library)
• Who is responsible for optimization: designer at the export stage or CI at the assembly stage

If this is not the case, each designer and each developer decides in their own way, and in six months PNG, JPG, SVG and WebP coexist in random order.

### Transfer to development

On the review of the layout, it is useful to explicitly sign assets: “logo – SVG”, “photo – WebP, 3 sizes”, “icons – from the library, do not export”. This removes half the chat questions and half the reworks.

If you’re working through Figma plugins or MCP integrations that unload assets automatically, check what’s gone. Automation quietly gives away PNG where SVG should be unless asked to. The tool doesn’t know what your “logo” is and what your “picture of a dish” is.

---

## Diagnostics: how to understand that the format is chosen incorrectly

No need to wait for complaints from users. Most problems can be seen in five minutes.

### Quick check in the browser

1. Open DevTools → Network → Filter by Img
2. Sort by size
3. Take a look at the top 10 heaviest pictures

We then ask three questions each:

• Is that a photo or a vector? If the vector weighs more than 100 KB, something is wrong.
• What format? If the PNG is more than 200 KB and it is not transparent over a complex background, the candidate for WebP.
• Where is this used? If the picture is shown in size 400 px, and given in 2400 px - excess weight for no reason.

### Signals at Lighthouse

In the report, pay attention to three points:

• "Serve images in next-gen formats" - a hint that somewhere is PNG/JPG instead of WebP/AVIF
• “Properly sized images” – more pictures than necessary
• “Efficiently encode images” – even in the right format, compression can be enhanced

These items are not cosmetic. Each of them is a specific megabyte that the user should not have downloaded.

---

## Typical errors in the layout review

• The logo in the header is exported as PNG because "it happened"
• Illustration-banner - SVG with traced photo inside
• Set icons - half SVG, half PNG, colors sewn into files
• Screenshot of the interface in the article is 2MB PNG, although WebP would give 200KB with no apparent difference
• User avatars – PNG with transparency, although there is a round mask and background is always filly

Each of these mistakes is a trifle. Ten of those little things on the page, and it takes twice as long to load.

### Questions you should ask yourself before giving the layout

• I can explain to each asset in the layout: why this format?
• Is there a PNG set that should have been SVG?
• Is there a SVG that actually rasters in the wrapper?
• Did I export in the right sizes or did I drop “as was”?
• Run SVG through the optimizer and rasters through compression?

If for all five - yes, the transfer will be short and without alterations. If you don't, it's better to spend ten minutes now than dealing with the Lighthouse report in a week.

## Advanced scenarios: where the format is particularly easy to miss

The basic rules “photo – WebP, icons – SVG” cover 80% of cases. The remaining 20% are exactly those situations where the site begins to slow down inexplicably or assets break down in unexpected places.

### Dark Theme and SVG

fill="#1a1a1a" icons look great in a light theme and become almost invisible in the dark. The right solution is fill="currentColor" and color management via CSS. If the icons come from the designer with hard-coded colors, the dark theme turns into manual editing of each file.

It is useful to check the icon in both themes directly in the browser, not just on the layout.

### Animated Assets

The most common mistake here is the export of animation as a GIF. GIF weighs many times more than it should, is limited in color and often looks dirty. Alternatives to weight loss:

• Lottie (JSON) – for vector animation from After Effects/Figma
• SVG animation for simple interface movements
• WebM/MP4 with autoplay muted loop – for everything that is captured by the camera or contains many pixels
• APNG/Animated WebP – narrow niches if transparency is needed

A GIF on a modern website is almost always a transmission error, not a conscious choice.

### Retina and pixel density

The picture, which is on the model 400×400, on the retina should be ready to show as 800×800. But this does not mean that you need to give all 2x devices – a phone with a regular screen will swing extra. The combination of srcset and sizes solves this, but only if the designer gave not one version, but a set.

Here is a useful mini-transfer format: file name with suffixes @1x, @2x, @3x or with a width in pixels. The developer does not have to guess what is in front of him.

### Icons in letters and PDF

If the asset goes beyond the site – in email, export to PDF, template for presentation – SVG may not be supported. Emails are safer than PNG. This is an exception, but it is regularly forgotten and then wondered why half of the subscribers in the mail empty squares.

---

## AI tools and auto generation of assets

Plugins, MCP integrations, and generative models are increasingly involved in graphics preparation. This changes the workflow, but does not eliminate the issue of format - and often on the contrary, exacerbates it.

### What makes AI good

• Turns a sketch into a pure vector
• Generates illustration options in a given style
• Mass resize and re-export assets
• Suggests alternative formats for file content

### Where AI is consistently wrong

• Gives the raster where the vector is needed, because "the picture is ready"
• Makes SVG with thousands of nodes from a simple form
• Ignores transparency or adds unnecessary alpha channel
• Save in PNG what WebP was supposed to be because PNG is the default format

The main risk of automation is that bad assets appear faster than the team has time to review them. One person would not put 40 PNGs of 1.5 MB in a repository. Script flooded.

### How to build a check

• In CI – step with svgo for SVG and sharp/squoosh for rasters, with a size threshold
• In the code review - an explicit point "new assets correspond to the format guide"
• Figma is a component library that uses icons instead of re-exporting the same thing

Automation is good as a filter of the final frontier, not as a substitute for a designer’s decision.

---

## How to explain the choice of format to the team

Developers and products rarely argue with designers over formats — but they don’t understand why “you can’t just PNG.” If you do not explain, in six months the project will again be screenshots of 3 MB.

### Arguments that work

• “WebP saves N kilobytes in this picture – on a mobile network, it’s a loading second.”
• “SVG scales without loss – the logo will not blur on the retin”
• “Sprite icons are cached once – the next page will open faster.”
• If you give one heavy picture, LCP will suffer, and this is the Core Web Vitals metric

Link the format not with taste, but with metrics. "It's more beautiful" is not an argument. “This will remove the yellow warning in Lighthouse and speed up the first rendering.”.

### Anti-Patterns of Communication

• Saying “SVG is better” without specifying why
• Demand rework without explaining what will break if left as is
• Silently cutting the assets after the developer - he will not understand what the mistake was, and repeat it

The short comment “the logo is better than SVG because it shows up in a cap on all screens and should be clear on the retina” saves an hour of controversy next time.

---

## Segment summary

Complex scenarios – dark theme, animation, retina, AI generation – are not exceptions to the rules, but places where the rules work most strictly. The team, who can explain the choice of format through metrics and user script, stops arguing about PNG and SVG and starts discussing the product.

## Checklist before Asset Committee

The same list that should be kept before your eyes when exporting and reviewing a pool request with a new graphics.

### Before exporting from Figma

• I understood where this asset will live: hero, icon in the button, background section, illustration in the card
• Determined the type: vector, photo, screenshot, illustration with gradients
• I chose the format consciously, not as usual: SVG for vector, WebP for photo and complex raster, PNG only if you need transparency and WebP for some reason is not suitable
• For raster prepared at least two densities - 1x and 2x - and understood what is needed at all
• Cleansed SVG of superfluous layers, effects and invisible objects
• Checked that transparency is needed - or, conversely, that it is definitely not
• The file name refers to the destination, not the frame number in the layout

### Before Murge, PR with Assets

• The size of the file fits into the budget of the page, not “well, it’s only 400 KB.”
• <img> has width, height and alt
• For raster given srcset and sizes, if the picture is shown at different widths
• The background is dark mode if it is in the product
• LCP image prioritized, the rest loading="lazy"
• SVG run through svgo or analog, raster clamped
• Icons are taken from a shared system, not a unique export "just for this page."

## Anti-patterns that repeat from project to project

### "I'll make a PNG to be sure."

The most frequent. PNG is perceived as a secure format – it is supported everywhere and will not break anything. The price is megabytes where hundreds of kilobytes would be enough. Safe for the designer, expensive for the user.

### One SVG logo for everything

A complex logo with gradients and shadows is unloaded into SVG because "the logo must be a vector." As a result, the file weighs like a PNG, renders slower, and in Safari it also looks different. Sometimes honest PNG@2x is the right choice.

### Icons are like pictures

Each icon is a separate file, connected via <img>, not managed via currentColor. When changing the theme, the icons do not change color, and you have to keep two sets. The solution is sprite or React/Vue components with built-in SVG.

### Screenshots from JPEG

Screenshot of the interface with text in JPEG is always soap on the letters. For screenshots with UI you need a lossless PNG or WebP, not a classic JPEG.

### "Zalya the original, the front will squeeze"

The designer throws 8MB from the camera, hoping that the CDN or build will fix everything. Sometimes they fix, sometimes they don't. And it's almost never fixed as well as conscious exports.

## Questions for design and code review

It is useful to ask them out loud - to yourself or a colleague - until they become a reflex.

• Is this asset really supposed to be a raster? What prevents it from being a vector?
• Is this image the LCP element of the page? How did we factor that in?
• How much does an Asset weigh and what page budget does it fall into?
• What will happen to him on the retinas? On the slow net? A dark topic?
• Where does this icon come from - from the library or is it a one-time export?
• If tomorrow's accent color changes, how many assets will have to be remade by hand?
• Is this file already in the project under a different name?

If the answer to half the questions is “I don’t know,” the asset isn’t ready for merge.

## Practical outcome

Choosing between SVG, PNG and WebP is not a matter of taste or dogma. This is a short chain of decisions: what content is, where it is shown, to whom and through which network, how it will live in a year.

A vector is for anything that can be described in shapes and needs to scale. WebP - for photos and complex raster, where weight is important. PNG is for transparency and cases where WebP is not suitable for the environment.

The team in which these decisions are made consciously and spoken at the review stops catching “incomprehensible” problems with performance and visual quality. Asset format is not design, it is part of the product.