How Do You Keep a Webflow Asset Library Under Control?

How Do You Keep a Webflow Asset Library Under Control?

Upload less, name things properly, convert to modern formats before you need to, and delete nothing until you know what uses it. An asset library goes bad slowly, through a hundred small uploads, and by the time anyone notices, nobody knows which of the four hero images is live.

We inherit Webflow projects regularly, and the assets panel is usually the clearest signal of how the site was built. A tidy library means someone was thinking. Two hundred files named screenshot and untitled means the site grew by accident.

Here is the approach we use, and the format decisions worth getting right at upload time rather than during a performance panic later.

Why Do Asset Libraries Get Messy So Fast?

Because uploading is frictionless and cleaning up is not. Every stakeholder review adds a file. Every version of a logo lands next to the last one. Nothing forces a decision, so nothing gets decided.

The deeper problem is that Webflow has no way to tell you whether a file is still referenced. An asset used on one CMS item looks identical to one used nowhere. That makes deletion feel risky, so files accumulate and the panel becomes a place you search rather than browse.

This matters more than tidiness. When nobody can tell which image is current, teams hedge by uploading a new one, and the library grows faster every month.

What Naming Convention Actually Survives?

One that a person can guess without training. We use purpose, then context, then variant: something like hero-pricing-dark. Not the date, not the designer's initials, not the version number, because those tell you about the file's history rather than its job.

The test is whether a new marketer joining in six months could find the pricing page hero by typing one word. If your convention requires a legend, it has failed, no matter how logical it looked in the spreadsheet.

Consistency matters more than the specific scheme. Any convention applied to everything beats the perfect convention applied to half the library.

Which Image Formats Should You Actually Upload?

AVIF where you can, WebP as the reliable default, and PNG only where you genuinely need it. MDN's own guidance puts numbers on the difference: lossy AVIF images are around 50 percent smaller than JPEG at visually similar quality, and AVIF generally compresses better than WebP, with median compression of about 50 percent against 30 percent for the same set of JPEGs.

WebP is the safer pick when support matters. MDN describes lossy WebP images as on average 25 to 35 percent smaller than JPEG at visually similar quality, lossless WebP as typically 26 percent smaller than the same PNG, and lists support across all versions of Chrome, Edge, Firefox, Opera and Safari.

For AVIF, MDN lists support from Chrome 85, Edge 121, Opera 71, Firefox 93 and Safari 16.1, and recommends providing a fallback in WebP, JPEG or PNG. We went deeper on that trade-off in our piece on AVIF versus WebP.

Does Webflow Handle Responsive Images for You?

Largely, and that is one of the genuine advantages of building there. Webflow generates smaller variants of uploaded images and serves them responsively, which means you are not hand-writing the srcset most teams get wrong.

It is still worth understanding what that machinery does. MDN describes srcset as listing image options with their intrinsic widths using the w unit, and sizes as telling the browser the width of the slot the image will fill, so it can pick before parsing your CSS. MDN's own example has an 800 pixel image at 128KB against a 480 pixel version at 63KB, a saving of 65KB on one image.

Knowing that helps you spot when the automatic behaviour is not enough, which is usually art direction: a wide landscape hero that needs a different crop on mobile rather than a smaller version of the same crop.

How Big Should the Source File Be?

Big enough for the largest slot it will ever fill, and no bigger. Uploading a 4000 pixel wide photograph for a card that renders at 400 pixels wastes storage, slows your editor and gains nothing, because the platform cannot invent detail you need but it will happily carry detail you do not.

Check the actual rendered width in the browser rather than guessing from the design file. Designs are drawn at one size and shipped at several, and the gap between them is where most oversized assets come from.

Limits and conversion quotas do change, so check Webflow's current help documentation for file size caps before planning a bulk upload rather than trusting a number from a blog post, including this one.

How Heavy Is the Average Site, for Context?

Heavier than most teams believe. The HTTP Archive Web Almanac for 2025, published in January 2026, reports mobile median page weights of 3,974 KB for Squarespace sites, 2,900 KB for Joomla and 2,894 KB for WordPress.

Images are usually the largest single contributor to those numbers, which is why asset discipline is a performance strategy rather than a housekeeping chore. A site that ships three unnecessary megabytes is not going to be rescued by a faster host.

Our guide to image optimisation for web performance covers the wider set of techniques, including where lazy loading helps and where it hurts.

What Should You Do About Alt Text?

Write it at upload time, in the assets panel, so it travels with the file. Retrofitting alt text across a finished site is a miserable job that gets half done, and the half that gets skipped is always the CMS images.

Describe the function, not the file. An image of a dashboard on a features page is not "dashboard screenshot", it is what the dashboard is showing and why the reader is looking at it. Decorative images should carry empty alt text so screen readers skip them rather than announcing a filename.

This is one of those tasks where doing it during production costs almost nothing and doing it afterwards costs a week. Our piece on Webflow accessibility covers where it fits in a build.

How Do You Safely Delete Anything?

Slowly, and with a record. Our approach is to rename a suspected orphan with a clear prefix, publish, wait a full content cycle, and then delete if nothing broke and nobody complained. It is tedious and it has never once caused an incident.

Before that, search the site for the filename, check every CMS collection that holds images, and check any rich text fields, which are where forgotten references hide. An image referenced inside rich text will not show up anywhere obvious.

If the project is large enough that this is impractical, the honest answer is to stop deleting and start preventing. A library of a thousand files where the current ones are clearly named is more workable than a library of six hundred where nobody trusts the names.

What Does Good Look Like After Six Months?

A library where the newest file is the current one, names describe jobs, every image has alt text, and nothing is uploaded at a size nobody will ever see. That state is reachable in an afternoon on a new project and takes a couple of days to establish on an old one.

The payoff is not aesthetic. It is that the next person, whether that is a new hire, an agency or an automated tool building variants of your pages, can work out what is current without asking anyone. That is worth far more than the storage you save.

If you have inherited a Webflow project and cannot tell what is live any more, we are happy to take a look with you. You can reach our team at phoenix.studio.