Why one logo becomes four files, and what that costs you

August 25, 2026 · 9 min read

Every condition you support adds an export. The work does not scale with your brand, it scales with the number of conditions.

The brand color changes. On paper it is one hex value. In practice it is a fortnight, and the reason is that the value is not stored in one place. It is stored in every file that was ever exported from it.

This is the tax nobody budgets for, because it is invisible until the day you owe it.

How a folder of variants accumulates

No one decides to maintain four copies of a logo. It happens in order, and each step is defensible:

The original export, in the brand color, on the assumption of a light background.
A dark-mode export, added the week dark mode shipped.
A small-screen lockup, added when the full horizontal mark stopped fitting on a phone.
A high-contrast export, added after somebody filed a ticket about it.

Four files, each correct, each created months apart by a different person for a different reason. The folder is not a mistake. It is the accumulated result of four correct decisions, which is exactly why nobody catches it.

And four is the polite number. Count again with an icon set of forty marks and the same four conditions and you are maintaining a hundred and sixty files that all encode the same handful of color decisions.

What the rebrand actually costs

For each variant of each mark, somebody has to:

Open the source file and change the color.
Export it again, with the same settings as last time, which are not written down anywhere.
Upload it to whatever serves it, under exactly the name the old one had.
Invalidate whatever cached it, including a CDN and any consumer that copied the file into their own project.
Check it, in the condition it exists for, which for the high-contrast variant means actually turning high contrast on.

That last one is where it fails. The light and dark versions get checked because everyone looks at them. The high-contrast file is the one nobody opens, so it is the one that keeps the old brand color for a year, in front of exactly the readers who most need it to be right.

Where the value should live

The technical form of this problem is familiar: a value that appears in many places instead of once. Every engineer knows the fix, because the fix is the same in every language. Name the value, refer to the name, change it in one place.

Artwork can do that too. Inside the file, the color becomes a declared token:

<style> svg { --brand: #0066cc; --ink: #14171a; --paper: #ffffff; } @media (prefers-color-scheme: dark) { svg { --brand: #00ccff; --ink: #f2f5f8; --paper: #161b21; } } .mark { fill: var(--brand); } .word { fill: var(--ink); } .plate { fill: var(--paper); } </style>

The rebrand is now the edit you thought you were making. Change --brand, and every mode follows, because every mode was reading it already. There is no second file to remember and no third file to forget.

And where it should live when there are forty of them

One file solves one mark. An icon set needs the value to live above the files, and inlined graphics get that for free, because they inherit from the page:

/* One definition, in the design system. */ :root { --brand: #0066cc; } @media (prefers-color-scheme: dark) { :root { --brand: #00ccff; } } /* Every inlined graphic reads it, keeping its own value as a fallback for the case where it is used standalone. */ svg .mark { fill: var(--brand, #0066cc); }

This is the point where the design system and the artwork stop being separate things that have to be kept in agreement. The token is the agreement. A designer changes it in one place, and forty graphics in four conditions each follow, without a developer transcribing anything and without an export step.

The fallback in that declaration matters, and it is easy to skip. It is what keeps the file correct when it is used outside the page that defines the token, which is every time somebody drops it into an email or a deck.

Count the copies before you argue about the fix

Before changing anything, it is worth measuring, because the number is usually larger than people expect and the measurement takes five minutes.

The second command strips the variant suffix and counts what is left. A line reading "4 ./assets/logo.svg" means four files exist for one mark. Run it on a real repository and the top of that list is the work you are doing every time the brand moves.

It is also the honest way to decide whether this matters to you. If every count is one, you do not have this problem and none of the rest of this post is worth your time.

The failure mode is silent, which is why it persists

A stale variant does not throw. Nothing in a build, a test suite or a deployment notices that logo-contrast.svg is still the old blue, because from the machine point of view it is a perfectly valid file that renders correctly.

It is only wrong relative to the other three, and nothing in the system knows the four are supposed to agree. That relationship exists in a designer head and in a folder naming convention, and neither of those is enforceable.

This is the general shape of the problem: duplicated state with no mechanism for keeping it consistent. Engineers recognize it immediately in code and tolerate it in assets, mostly because assets have not historically had a way to express "these are all the same thing".

What changes when the value has one home

Consolidating is not only about doing less work at rebrand time. It changes which mistakes are possible.

A mode cannot be forgotten, because there is no separate artifact to forget. Change the token and the dark rendering changes with it.
Two modes cannot disagree, because they are computed from the same declaration rather than drawn independently.
A reviewer can see the whole decision in one place. Reviewing four exported files means opening four binaries and comparing them by eye.
The change is reviewable as a diff. A color change in a text file is one line in a pull request, which is a thing a person can approve.

That last point is the one engineers care about most and it is rarely mentioned. Binary assets are invisible to code review. A text-based graphic with named values is not: the change shows up in the diff, next to the code, where the same review process that catches everything else can catch it.

svg { - --brand: #0066cc; + --brand: #1a4fd6; --ink: #14171a; }

Six lines of context and one changed value. Compare that to a pull request that says "updated logo assets" and contains four files nobody can read.

What to tell the people who have to approve this

Consolidating variants is an easy sell to engineers and a harder one to whoever owns the brand, because from the outside it sounds like giving up control of how the logo appears.

The opposite is true, and it is worth saying plainly. Today the brand is enforced by four files that anyone can replace independently and that nothing checks against each other. After consolidating, the brand is enforced by a set of named values in one file, in version control, where a change is a reviewable diff and a reviewer can see the whole decision at once.

Three questions usually come up, so here are the answers:

Does the logo still render identically in the default case? Yes. The light-mode drawing is the same drawing, with its colors declared as names rather than repeated as literals.
Can somebody accidentally change the dark version without changing the light one? No, and that is the point. They are computed from the same declaration, so they cannot drift apart.
What if we genuinely need a different drawing for dark mode, not a recolored one? Then it is a different drawing and it should stay a separate file. This approach is for the case where the modes are the same artwork under different conditions, which is the overwhelming majority.

The last one is worth taking seriously rather than arguing away. A wordmark that becomes a monogram below a breakpoint can be handled in one file, because it is the same artwork with a piece hidden. An illustration that is genuinely redrawn for dark mode cannot, and should not be forced into one.

Migrating without a big-bang rewrite

Nobody should consolidate a hundred and sixty files in one afternoon, and you do not have to. The migration works incrementally because the output is a standard SVG that drops into the place the old one occupied.

Start with the mark that has the most variants. It is the highest cost and the clearest proof.
Replace the light-mode file first, keeping the same path and filename, so nothing that references it has to change.
Delete the variants once the replacement is confirmed in each condition, rather than before.
Remove the picture element or the theme prop that used to choose between them. This is the step where the code gets smaller.
Repeat for the next mark. There is no coordination point and no flag day.

The absence of a flag day is the practical argument. A migration that can stop halfway and leave the site working is a migration that will actually get finished.

What it costs to be wrong about this

A stale high-contrast logo is a small thing. The reason to care is who it is small for.

The reader running forced colors has told their operating system that the default palette does not work for them. They are, by definition, the reader least able to absorb a graphic that ignores the setting. And that variant is the one that goes stale, every time, because it is the one nobody has a reason to open.

Consolidating removes the possibility rather than the symptom. There is no separate high-contrast file to go stale, because the high-contrast behavior is a block in the same file as everything else, changing with it.

What we will and will not claim about size

It would be easy to put a percentage here. We are not going to, because the honest answer depends on the artwork.

One adaptive file carries slightly more markup than any single export, because it contains the rules as well as the drawing. It also removes the duplication of three entire drawings. For a mark of any complexity the second effect is much larger than the first, but "much larger" is not a number we can promise for your file without seeing it.

What is not a judgment call is the count. One request instead of four. One object to store instead of four. One thing to invalidate instead of four, and no chance of invalidating three of them.

When a folder of variants is still the right answer

There are cases where none of this applies, and pretending otherwise would waste your afternoon:

Photographic content. This is vector territory. A photograph is not a candidate and we will tell you so rather than hand you something that looks broken.
Artwork whose conditions differ by more than color and layout. If the dark version is a genuinely different illustration rather than the same drawing recolored, it is a different drawing, and it should be a different file.
Environments that will not accept inline SVG and where you also need page-token inheritance. The file still adapts on its own, but the inheritance needs inlining.

Everywhere else, the question worth asking is simply how many copies of one decision you are currently maintaining, and what it will cost the next time that decision changes.

Where to start

Pick the mark that has the most variants. That is where the tax is highest and where the answer is most obvious. Put it through on the free account, look at what comes back, and tell us where it falls short. Every report goes on our public board.

Post Details

Published

August 25, 2026 · 9 min read

A rebrand should be one edit.

With a folder of exports, a color change means reopening the source, exporting each variant again, re-uploading each one and clearing whatever cached them. Four chances to ship a mismatch, and the file nobody checks is the high-contrast one.

With the conditions inside a single file, the palette is a set of tokens near the top. Change them once and every mode follows, because every mode was reading them already.

This is what the beta is for. Join us and bring the artwork you think will break it.

Questions about consolidating variants

Usually, and we will not promise it in every case. The file carries a little more markup than any single export and it removes the duplication of three whole drawings, so the comparison depends on the artwork. What is certain is that it is one request instead of four and one thing to store instead of four.

Vector art: icons, logos, diagrams, illustrations and interface graphics, including previously vector-based art that can be reconstructed. Not photographs, and not every image. The boundary is real and we would rather say so than hand you something that looks broken.

Not usually. It is a standard SVG, so it drops into the place the old one occupied. The exception is if you want the graphic to follow your own page tokens, which needs it inlined rather than referenced.

Start on the free account and put a real graphic through it. The awkward ones teach us the most, and every report goes on our public board.