The Art Of Responsive Drawing

Getting SVG Illustrations To Actually Work Across Viewports

Most people treat responsive illustrations like they're just resizing images. That's the quickest way to end up with a blob in the corner of a mobile screen. The actual process is a lot more involved, and honestly, a lot more boring if you're looking for drama. At its core, responsive drawing means creating visual assets that maintain their intended appearance regardless of the viewport they're displayed in. This typically involves SVG-based illustration, proper viewBox configuration, and CSS media queries that target individual elements within the artwork rather than trying to scale the entire thing uniformly. I spent about six months working through this properly, mostly because I kept seeing the same mistakes on production sites. A team would drop in a beautifully detailed SVG hero illustration, set it to width: 100%, and call it a day. Then on a 320-pixel-wide phone, you'd get a tiny version where every detail was lost and the text underneath became unreadable against the background.

The fix is not "make the SVG smaller." The fix is thinking about which parts of your illustration actually matter at small sizes and restructuring accordingly.

Setting Up Your ViewBox Correctly

Every SVG needs a viewBox attribute that defines its internal coordinate system. This is where most people go wrong. You'll see attributes like viewBox="0 0 800 600" paired with inline styles forcing width="100%" height="100%". That works fine on desktop, but it breaks the moment you need that illustration to reflow. Instead, give your viewBox a reasonable aspect ratio that matches your intended display area, and use the preserveAspectRatio attribute to control how the SVG fills that space. For most responsive illustrations, you want something like preserveAspectRatio="xMidYMid meet" so the image scales down proportionally without clipping. If your illustration is meant to serve as a background, use "xMidYMid slice" to ensure it covers the area even if it means cropping content. The difference between those two approaches is the difference between a clean responsive layout and one where half your illustration disappears when someone switches to portrait mode on a tablet.

Structuring SVGs For Responsive Behavior

A single flat SVG is fine for a simple icon. It's not fine for anything that needs to adapt to different screen sizes. You need to think in layers and groups. Break your illustration into logical groups using tags with class names that correspond to the responsive behavior you want. A background layer might always be visible. A detailed foreground element might only appear at larger breakpoints. Text labels should absolutely be separated out so they can be repositioned independently. I had a project once where we built a four-panel infographic-style SVG that showed a data flow diagram. On desktop, all four panels sat side by side. On mobile, they needed to stack vertically. The naive approach was to just let the SVG shrink, which made everything microscopic. The working approach was to use CSS to hide and reposition individual groups based on viewport width, combined with a separate SVG structure that had the mobile layout baked in.

That meant maintaining two versions of the same illustration, which felt wasteful at first. In practice, the two versions shared about eighty percent of the same code. The mobile-specific part was just a handful of class changes and positioning adjustments. I ended up using a build step that compiled both from a single source, so the maintenance burden was minimal.

CSS Media Queries Inside SVG

One thing that catches people off guard is that you can put CSS directly inside an SVG file. Not just presentation attributes, actual style blocks with media queries. This means you can write rules like: #detail-layer { display: none; } @media (min-width: 768px) { #detail-layer { display: block; } } This lets you control the visibility and positioning of individual illustration elements without wrapping the SVG in external containers or managing layout from the parent HTML. It keeps everything self-contained, which matters when you're dealing with multiple content editors who shouldn't be touching layout code.

There's a trade-off though. Inline styles inside SVG can make the markup harder to read and debug, especially when you're dealing with files that are thousands of lines long. I usually keep the CSS in a separate stylesheet when possible and reference it via a linked resource, but that doesn't always work depending on your hosting setup or whether you're serving SVGs from a CDN.

Typography In Responsive Illustrations

If your illustration contains text, treating it the same way as vector shapes will break things quickly. Text inside SVG scales with the image, which means it becomes unreadable at small sizes. The solution is to use em or rem units for font sizes within the SVG, and to set explicit max-width constraints so text wraps instead of overflowing its container. Even better, keep critical text outside the SVG entirely. Use HTML elements positioned over or alongside the illustration where the content needs to adapt independently. This gives you full control over line lengths, font sizes, and breakpoints without being constrained by the SVG's internal coordinate system. It also improves accessibility since screen readers can parse the HTML text directly. I learned this the hard way on a project where we embedded a quote directly inside an SVG. It looked great on desktop. On a Galaxy S5, the text was compressed to about eight pixels tall and completely illegible. Moving that text to a positioned HTML element fixed it immediately.

Performance Considerations

Large SVG illustrations can tank your page load time, especially on mobile networks. A detailed product illustration I worked on clocked in at around 140 kilobytes uncompressed. That's acceptable for a single hero image on a home page, but it becomes a serious problem when you're including multiple illustrations across a multi-page site. Compression helps. SVGO is the standard tool for this and it typically reduces file size by forty to sixty percent without any visible quality loss on most illustrations. You can also strip out unnecessary metadata, comments, and hidden layers before serving the file. Another option is to use different SVG versions for different breakpoints, which means you're only downloading the detail level that's actually visible. The trade-off with breakpoint-specific SVGs is that you're maintaining more files and your build pipeline gets more complex. For a small site with a few illustrations, SVGO compression alone is probably sufficient. For a large design system with dozens of custom illustrations, the extra effort pays off quickly.

When Responsive Drawing Doesn't Work

Sometimes the right answer is not to make your illustration responsive. Raster images (PNG, JPEG) are the better choice when your illustration contains photographic elements, gradients that don't scale well at small sizes, or when the detail level is so high that even an optimized SVG would be over a megabyte. WebP is worth considering as an alternative format for complex illustrations since it offers both compression efficiency and transparency support. There are also cases where a fully vector approach simply cannot replicate the visual quality you're going for. Hand-drawn textures, complex shading, and photographic composites all behave better as raster images. The rule of thumb I use is: if the illustration would require more than about fifty individual vector shapes to recreate faithfully, it's probably better served as a raster image with responsive CSS sizing. Responsive drawing is a specific tool, not a universal solution. It works well for diagrammatic illustrations, icon systems, infographic elements, and clean geometric designs. It works less well for anything that relies heavily on photographic realism or complex organic textures. Knowing which category your illustration falls into before you start building saves a lot of time.