A folder of image files doesn’t scale. The moment the same picture needs three formats, two sizes, and a way to be found, you need a model, and it’s smaller than you’d think.
An image vault (a small digital-asset manager) is the authority for what every picture is and means, separate from wherever those pictures are displayed. It answers two questions a file system can’t: “is this the same image I already have?” and “which image means X?” Everything below is how three concepts answer both.
Table of Contents
The problem: thousands of images, each needed many ways
At any real scale, one logical picture is needed in several concrete forms: a large hero, a social-card crop, a thumbnail, sometimes a vector master and a raster fallback. Keep them as files in folders and three problems compound. The same image, re-saved for two pages, becomes two files nobody knows are identical. A picture perfect for a new page is unfindable because nothing records what it depicts. And there’s no place to say “these five files are all the same asset in different clothes.” A vault exists to make those statements once and reuse them.
Three concepts: asset, rendition, tag
- Asset: the logical image, the thing that means something. Its identity is the hash of its content, not a filename or a path. Two uploads of the same bytes are the same asset, automatically.
- Rendition: a concrete file of an asset: its master (the source of truth, such as an authored SVG or an original photograph) plus deliveries derived from it (a WebP for the web, a PNG where transparency matters). Renditions are distinguished by format, size tier, and variant; the master is one rendition among them, marked as the original.
- Tag: a unit of meaning attached to the asset: what it depicts, the concept it serves, its style, its role.
That’s the whole vocabulary. An asset has renditions and carries tags.
The one rule: tag the asset, not the rendition
This is the move that makes the model pay off. Meaning lives on the asset, so every rendition inherits it. Tag an asset as “cybersecurity, shield, security” once, and its SVG master, its WebP delivery, and its PNG fallback are all findable by those terms, because they’re the same asset wearing different formats.
The practical consequence people miss: you never “tag the PNG separately.” If someone asks whether the raster version also needs metadata, the answer is no: it’s a rendition of an already-described asset. Tagging renditions would mean re-describing the same picture once per format, drifting out of sync the moment one copy is edited. Attaching meaning to the logical asset keeps it single-sourced.
A rendition is the same asset in different clothes; you describe the person, not each outfit.
Identity = the HASH of its bytes, not a filename. Two uploads of the same bytes are one asset. Stored once – automatic deduplication.
The MASTER (source of truth: an authored SVG, or an original photo) plus derived DELIVERIES (WebP, PNG). Distinguished by format/size/variant.
What it depicts, the concept it serves, its style, its role. Attached to the logical asset, not to any one file.
Meaning lives on the asset, so every rendition inherits it. You never tag the PNG separately. One description, single-sourced, no drift.
A rendition is the same asset in different clothes; you describe the person, not each outfit.
Content-addressed identity: vault once, re-run safely
Because an asset’s identity is the hash of its bytes, the vault gets two properties for free. Deduplication: the same image ingested from two places collapses to one stored copy, with no silent duplicates. Idempotency: re-running an ingest of already-vaulted images writes nothing new, so a batch job is safe to repeat and safe to resume after a failure. Identity-by-content is what lets you treat “put these images in the vault” as a repeatable operation rather than a one-shot you’re afraid to run twice — the same idempotency a store-writing tool depends on.
Master vs delivery: store truth once, render the rest
Keep the master as the source of truth and generate the delivery formats on export rather than storing hand-made copies. A vector hero is stored as its SVG and rendered to WebP/PNG when something needs a raster, because social scrapers and card unfurlers can’t read SVG, but the SVG stays the authority (the mechanics of that conversion are their own topic — see Render SVG to WebP on Export). A photograph is stored as its original with a WebP delivery derived from it. Either way, one master, many deliveries, and the deliveries are reproducible, so you never lose the source by shipping a compressed copy.
This is the asset/rendition split doing its job: the master and its deliveries are all renditions of one asset, one description covers them, and the vault can regenerate a delivery it discarded because it kept the truth.
Reuse: one image, one post, checked before publishing
A vault makes reuse easy, and that’s a trap of its own. When we audited our own site (129 published posts, 194 distinct images), no featured image appeared twice, but seven in-body images appeared in more than one post. The worst, a security illustration, was in four. Each reuse was reasonable when it happened. Together they made different articles look interchangeable, and a reader who meets the same picture twice stops reading it as part of either article.
So we set a limit for each kind of image, per site:
| Kind of image | Posts it may appear in |
|---|---|
| Featured image, or an illustration in the body | 1 |
| Evidence: a screenshot or capture of one real result | 2, and only when both posts declare they share it |
| Library assets (logos, brand marks) | unlimited |
Evidence gets the exception because a screenshot of one test result can honestly support two articles about that result. An illustration can’t: it belongs to the idea it was drawn for.
A rule like this only holds if something checks it. Our linter now reads every draft before publishing and counts each image reference, both the featured image and every image in the body. A second use fails the build and names the posts involved. It also checks that both posts declare a shared screenshot. The fix is usually one of three things: an unused image from the vault, an authored figure made for that post, or a link to the post that already owns the picture.
Here the vault’s other half paid off. Because every asset carries tags, one query listed the twenty sample renders from our illustration kit, and sixteen of them had never appeared in any post. Three of the affected articles got their own picture from that list the same day; the fourth got an authored figure drawn for it. After the swap, the whole library passed the check with no errors.
A vault makes an image easy to reuse; a count before publishing keeps it from being reused on the same site.
The short version
A folder of image files doesn’t scale; a three-part model does. An asset is the logical picture, identified by its content hash so it’s stored once. A rendition is a concrete file of that asset: a source-of-truth master plus derived deliveries. A tag is meaning, and the rule that does most of the work is that tags live on the asset, so every rendition inherits them and you never re-tag a format. Content addressing gives you dedup and safe, repeatable ingests; keeping the master and rendering deliveries on export means you store truth once and serve whatever a consumer needs. Limit reuse on any one site (one post per illustration, two for shared evidence) and count image references before publishing, because easy reuse quietly turns into the same picture everywhere. What meaning to attach (so one asset can serve many roles) is the next layer.
Frequently Asked Questions
What’s the difference between an asset and a rendition?
The asset is the logical image (identified by its content, carrying the meaning); a rendition is one concrete file of it, the master or a derived delivery in a given format and size. One asset, many renditions.
Do I tag each format separately?
No, and that’s the whole point. Tags live on the asset, so the SVG, WebP, and PNG renditions all inherit them. Re-tagging per format only invites drift.
Why identify assets by a content hash instead of a filename?
So the same image is recognized as the same asset no matter where it came from, giving automatic deduplication and making re-ingesting a safe no-op instead of a duplicate.
Should I store a vector or a raster?
Store the master — the SVG for authored vector art, the original for a photograph — and render raster deliveries on export. You keep the source of truth and can regenerate any delivery; see Render SVG to WebP on Export.
Can the same image appear in two articles on one site?
Not if it’s an illustration: give each article its own picture, or link to the post that owns it. A screenshot of one real result may appear in two articles about that result, if both say so. Checking this needs a count across every post before publishing, because each reuse looks reasonable on its own.
Isn’t this just a folder with a database?
It’s a database of meaning and identity over a content-addressed store. The store holds bytes once; the database records what each asset is, what renditions it has, and what it means: the parts a folder can’t answer.
