SVG Logos and Asset Pipelines
Managing SVG logos across a production pipeline requires more discipline than most teams expect. The format is powerful but demands consistent handling to avoid asset sprawl.
The Deceptive Simplicity of SVG
SVG has become the default format for logos and icon systems on the web, and for good reason. Resolution independence, small file sizes, CSS controllability, and animation potential make it objectively superior to raster formats for most graphic assets. But the format's flexibility is also its risk. An SVG file can contain almost anything—embedded rasters, JavaScript, font definitions, filter effects, metadata bloat from design tools—and the production pipeline needs to handle all of that gracefully.
Most teams adopt SVG logos and icons without establishing a pipeline for managing them. The result is predictable: inconsistent optimisation, files that vary wildly in internal structure, viewBox inconsistencies that cause sizing surprises, and accumulated cruft from design tool exports that inflates file sizes without adding visual value.
This article walks through the practical decisions involved in managing SVG assets at production scale, from export settings through optimisation, integration, and ongoing maintenance. The focus is on logos specifically, though most principles apply to icon systems as well.
Export Discipline
The SVG pipeline starts at export. Every design tool exports SVG differently, and the default export settings from most tools produce files that need significant cleanup before production use.
Common export problems include: embedded font definitions that duplicate fonts already loaded by the page, preserved layer names that expose internal design nomenclature, unnecessary group wrappers that add DOM depth without visual effect, transform attributes that could be baked into path coordinates, and metadata blocks that contribute nothing to rendering.
The first pipeline rule is to establish a consistent export configuration and document it. Whether the team uses Figma, Illustrator, Sketch, or another tool, the export settings should be specified and followed by everyone who produces SVG assets. Convert text to outlines before export (for logos, not for editable text elements). Flatten transforms where possible. Use presentation attributes rather than inline styles unless CSS controllability is a requirement.
The second rule is to separate the design source from the production asset. The SVG file in the design tool is not the same as the SVG file in the codebase. They serve different purposes and may need different structures. Treating them as interchangeable introduces fragility.
Optimisation and Cleanup
Raw SVG exports from design tools typically contain thirty to sixty percent more markup than necessary. An optimisation step is not optional for production assets—it is a baseline requirement.
SVGO remains the standard tool for automated SVG optimisation. It strips metadata, collapses unnecessary groups, shortens path data, removes empty attributes, and applies dozens of other transformations that reduce file size without affecting visual output. Running SVGO as part of the build pipeline ensures that every SVG asset meets a minimum quality standard regardless of who exported it.
However, SVGO's default configuration is aggressive enough to occasionally break SVGs that depend on specific structural features. Logos with mask elements, clip paths, or gradient definitions can lose visual fidelity if SVGO collapses the definitions they depend on. The solution is a tuned SVGO configuration that enables the safe optimisations and disables the destructive ones, tested against the actual asset library.
The W3C SVG specification defines the full set of elements and attributes that SVG supports. Understanding which elements are structural (and must be preserved) versus presentational (and can be simplified) is the foundation of effective optimisation.
Manual review is still necessary for key brand assets. Run the logo through SVGO, then compare the output visually against the original at multiple sizes. Some optimisations that are invisible at large sizes become visible at small sizes, particularly rounding of path coordinates that affects curve smoothness.
ViewBox and Sizing
The viewBox attribute is one of the most misunderstood aspects of SVG for web use. It defines the coordinate system of the SVG content, and getting it right is essential for consistent scaling behaviour.
Every production SVG logo should have a viewBox attribute and should not have explicit width and height attributes hardcoded into the SVG markup. This allows the logo to scale fluidly based on its CSS container while maintaining its aspect ratio. If width and height are needed for layout purposes, apply them via CSS or HTML attributes on the element that embeds the SVG, not in the SVG file itself.
The viewBox values should tightly crop the visible content. Design tool exports often include a viewBox that matches the artboard size, which may include padding around the logo. That padding becomes problematic when the logo is sized in a container that already provides spacing—the result is a logo that appears smaller than intended because invisible padding is consuming part of the available space.
Establish a standard process for auditing and correcting viewBox values. For logo assets, the viewBox should describe the tightest bounding box around the visible content, with no additional padding.
Inline SVG vs External Reference
There are two primary methods for embedding SVG logos in a web page: inline SVG (the markup lives directly in the HTML) and external reference (the SVG file is referenced via , or CSS background-image).
Inline SVG provides the most control. The SVG elements are part of the DOM, so they can be styled with CSS, animated with JavaScript, and respond to interaction events. For logos that need to change colour based on page context—light logo on a dark section, dark logo on a light section—inline SVG is the practical choice.
External reference is simpler and allows browser caching. The SVG file loads once and can be cached independently of the HTML. But CSS control is limited to the SVG's internal styles; you cannot restyle individual paths from the parent page's stylesheet.
For most logo implementations, inline SVG is the better choice. The file sizes are small enough that the caching benefit of external reference is marginal, and the styling flexibility of inline SVG justifies the slightly larger HTML payload.
When using inline SVG, implement it through a component that renders the SVG markup directly in the template. Avoid injecting SVG via dangerouslySetInnerHTML or equivalent—use a proper component that produces structured, predictable output.
Colour Management
Logo SVGs that need to respond to their context—adapting between light and dark versions, for example—require deliberate colour management in the SVG markup.
The cleanest approach is to use currentColor as the fill and stroke value for paths that should inherit colour from the surrounding context. When the SVG is inline, currentColor resolves to the CSS color property of the SVG element or its ancestor, allowing the logo colour to be controlled entirely through CSS.
For logos with multiple colour zones (a wordmark in one colour and an icon in another), use CSS custom properties or class-based selectors on internal SVG groups. Define colour assignments in a stylesheet rather than hardcoding hex values in the SVG paths. This centralises colour management and makes theming straightforward.
Pipeline Integration
The SVG pipeline should be integrated into the project's build system rather than running as a manual step. At minimum, the pipeline should include: export validation (checking for common export issues), SVGO optimisation, viewBox audit, and output verification.
For teams that produce SVGs infrequently, a pre-commit hook that runs optimisation on changed SVG files is sufficient. For teams with active design workflows producing SVGs regularly, a more formal pipeline with staging, review, and automated visual regression testing is worth the investment.
Store the SVGO configuration in the repository, version-controlled alongside the assets it processes. When the configuration changes, the entire asset library can be reprocessed to ensure consistency.
Frequently Asked Questions
Should logos use SVG even if they are simple enough for a single-colour PNG?
Yes. SVG scales without degradation, typically produces smaller file sizes than equivalent PNGs, and supports CSS colour changes. Even for the simplest logos, SVG is the better format.
How do you handle SVG logos in email templates?
Email clients have inconsistent SVG support. For email, export the logo as a well-optimised PNG at 2x resolution. SVG remains the web format; email is a separate concern with different constraints.
What about animated SVG logos?
Keep logo animations subtle and brief. Use CSS animations for simple property changes and SMIL or JavaScript for path animations. Ensure the logo renders correctly with animation disabled, respecting the user's motion preference.