Coded Graphics: A Better Way to Build Website Visuals

Most website sections need a visual. There is an option besides photos and generated images that most people building sites do not know they already have.

A coded graphic is a picture your website draws instead of downloads.

Your site already draws shapes constantly. Every button is a rounded rectangle with a border, a fill color, and a shadow. Every card is a box. Your page draws hundreds of them on every load.

Arrange those same shapes deliberately and you have a graphic. An app window, a dashboard, a media player, a set of stacked cards. No image file involved.

You have seen them. Many software product sites use them. People often assume they are screenshots when they are not.

An image is a download. The browser requests the file, waits for it, then draws it. A 400KB image on a slow connection is a visible delay.

A coded graphic is not a download. It is instructions already in the page. Nothing to request, nothing to wait for. It renders as the page renders.

Five images on a page means five separate requests. Five coded graphics means zero.

Whether that is noticeable depends on how large your images are and how many of them there are. On a page carrying one small image it is marginal. On a page with a large hero image it can be the difference between a fast load and a slow one. Page speed is a ranking factor for Google, and Largest Contentful Paint, the measurement of how long your biggest visual element takes to appear, is often determined by a hero image.

Your brand color is a specific value. Something like #2563EB.

You cannot hand an image generator a hex code and reliably get that exact value back. You get something in the neighborhood. Sitting next to a real button using the actual value, it can read as slightly off. Not obviously wrong, just imported.

A coded graphic can reference the same color variable your buttons reference. Build it that way rather than typing a hex code into it, and it stays matched, including if you change your brand color later. The same applies to border radius, shadow depth, fonts, and spacing. Built with your existing values, it inherits your design system instead of imitating it.

Images have fixed dimensions. Shrink one for mobile and everything inside gets smaller, including any text, which can end up unreadable.

Coded graphics are built from layout rules, so you can specify different behavior at different screen sizes. On a phone, elements can restack, padding can tighten, and text can hold its size rather than shrinking with everything else. That is something you build in deliberately, not something that happens for free.

Zoom in and nothing pixelates. There are no pixels, just shapes redrawn at whatever size is needed.

An image arrives finished. Wrong color means generating a new one, or opening a design tool to edit, export, re-upload, replace.

A coded graphic is a set of parts. Every piece is adjustable on its own. Make the labels bigger and only the labels change. Tilt one panel further and nothing else moves.

You are not rolling dice on a new version. You are adjusting the one you have.

An image is generic by nature. You find something in the neighborhood of your topic and write your copy around it.

A coded graphic can be built to show the specific thing that section is about. A section about a four phase program can show four phases, with the first one active and a progress bar partway across. A section about connected systems can show which things connect and which do not. A section about a course can show a player, a progress bar, and what comes next.

You are not settling for close enough.

You do not write the code. You describe what you want and AI writes it into your site.

Most modern builders have AI built in. I build on ESTAGE with Claude connected directly to my project, so I describe the graphic in chat and it lands in the page. ESTAGE has its own Genesis builder that does the same thing from inside the platform.

The part that determines whether this works is describing a physical object rather than a concept.

A concept: a graphic that represents our onboarding process. That produces vague shapes, because you have given it nothing to draw.

A card with a header bar, a progress bar filled about a third of the way, and two more items listed underneath with the second one grayed out, with two more cards layered behind it at slight angles.

That one works because every part of it is a thing. A header bar is a thing. A progress bar at one third is a thing. A card tilted behind another card is a thing.

Two practical notes from building a set of these. First, say what is layered behind. In my case a single element filling the frame tended to read as more page rather than as a picture, and naming what sits behind it, and at what angle, made more difference than anything else I tried. Second, correct one thing at a time. Make the labels bigger. Tilt the back panel further. One instruction, one change, everything else untouched. That control is the main advantage over generating an image, but only if you use it that way.

If you find yourself writing an adjective like modern or clean, you have drifted back into concept territory.

A regular image has alt text, which screen readers announce.

A coded graphic has none by default. There is no image file for a screen reader to find, so unless you add something, it is announced as nothing at all, a silent gap where your visual sits.

The fix is two attributes. One tells assistive technology that this collection of shapes is a picture. The other holds a written description of what it depicts.

Write that description carefully, because it is easy to get wrong in a specific way. The instinct is to describe the shapes: three windows stacked apart with lines between them that stop short. Someone hearing that learns nothing. It describes geometry and leaves out the point.

Describe what it means instead: an illustration of fragmented systems, separate business tools sitting apart from each other, with connections that never link up. Now the description carries the same argument the picture carries.

One more thing to check. Any text inside your graphic still has to meet contrast requirements. Small light gray text on a dark card sitting on another dark panel will likely fail, and it is easy to end up there without noticing. Worth checking with a contrast tool rather than assuming.

Sections explaining a system, a process, or a problem. The abstract things that are hard to photograph, which is exactly where generic visuals accumulate on most sites.

If you have a section where you dropped something in because you needed something there, that is the one to try first.