Smart SVG™ by Equivalent
Join our betaContact us

How a Smart SVG™ is made

The six layers behind one adaptive file, from the artwork you upload to the file you ship.

How a Smart SVG™ is made Six layers. One file, or the set of variants a team already ships, is ingested through the web app or the API, validated and queued, rebuilt as scalable geometry, given a readable name and description, given rules for light and dark, small screens and high contrast, and returned as one file. How a Smart SVG™ is made One file or a set of variants in, one adaptive file out. Six layers, start to finish. 1 Asset ingestion One file, or the set of variants you ship today, through the web app or the API. 2 Processing pipeline Every file is checked, cleaned and queued. Nothing that could execute survives the door. 3 SVG transformation The artwork is rebuilt as scalable geometry, with the unnecessary weight removed. 4 Accessibility A readable name and description are written inside the file, so they travel wherever it goes. 5 Adaptive rendering Rules for light and dark mode, narrow screens and high contrast, carried in the file. 6 Delivery and API One file comes back, ready to drop into any site or app. No runtime, no library to add. How a Smart SVG™ is made 1 Asset ingestion 2 Processing pipeline 3 SVG transformation 4 Accessibility 5 Adaptive rendering 6 Delivery and API

A Smart SVG™ is built in six layers. Your artwork goes in, and what comes back is one file that already knows what to do in dark mode, on a narrow screen, under high contrast, and in front of a screen reader.

Here is the whole path at a glance, and then each layer in turn.

The six layers

1

Asset ingestion

Send a single graphic, or the whole variant set you ship today: the light logo, the dark one, the small-screen mark. Where several files describe the same artwork they are read together, so the differences between them become the conditions the finished file answers rather than four separate downloads. SVG, PNG, JPEG and WebP all come in, through the web app or one API call. Photographs are the thing to leave out, because there is no geometry under a photograph to recover, only pixels.

2

Processing pipeline

An SVG is code, which is exactly why this step exists. The code that makes a graphic adaptive is declarative: markup the browser draws, and CSS it evaluates while drawing. The code that does not belong is the executable kind, meaning scripts, event handlers, and references that reach out to another server while someone is looking at your page. Those are stripped on the way in, along with the editor residue that inflates a file: hidden layers, unused definitions, and coordinates carried to more decimal places than any screen can render. What continues is smaller, and can only draw.

3

SVG transformation

With the file clean, the drawing is rebuilt so one set of shapes can serve every condition. Colors become named custom properties instead of hex values repeated at each shape, so changing a palette reaches the whole graphic at once instead of forty times. Where a variant set came in, the differences between those files become the rules this one file switches on. The result is still an ordinary SVG that every browser already knows how to draw.

4

Accessibility

The name and description a screen reader announces are written into the file itself, as title and description elements the markup points at. This matters because alt text lives on the page rather than in the picture: the moment a graphic is reused somewhere else, that description is left behind and the image arrives unnamed. A name carried inside travels with the file through every page, CMS and design tool it passes through. It does not make a page conformant on its own, and no tool can promise that, but it removes the single most common failure.

5

Adaptive rendering

The conditions are written as media queries the browser already supports: prefers-color-scheme for dark mode, a width breakpoint for narrow screens, forced-colors for high contrast, prefers-reduced-motion wherever there is movement. Because they are declarative, the browser resolves them while it paints. Nothing waits on a script, and there is no flash of the wrong version while JavaScript decides which one to show. The file behaves correctly even where your code is not running at all.

6

Delivery and API

One file comes back. Reference it with an img tag, inline it, or commit it: there is no runtime to install, no library to hold at a version, and nothing to configure. Because it is text in the XML family, it diffs in a pull request like the rest of your source, and the pipeline you already have compresses and caches it exactly as it handles any other SVG. If this service vanished tomorrow, every file it produced would keep working.

Join our beta