SVG icons on a site: where layout issues begin
An icon drawn for a specific block in a mockup lives until the first re-layout.
As soon as you add a new section or change the grid width — and SVG icons begin to behave unpredictably: some stretch with the container and lose proportions, others are cropped at the edge, and still others stop matching the optical size of their neighbors.
Formally, these are layout problems, but behind them are not style properties, but the way the graphics are prepared.
Style desynchronization most often comes from parallel work. One contractor drew outline icons with one stroke width, another used fill, a third pulled in a ready-made set from someone else's library.
Within a section everything looks neat, but at the junction of blocks you can see different corner radii, different padding around the icon, and a hover state that works for only half of the site icons. This cannot be fixed with styles alone — the edits affect the files themselves.
Page weight grows quietly. Usually a project contains raster copies of the same icon in several sizes, a full sprite where only a tenth is used, and an icon font for the sake of two arrows.
Each set loads on all pages, including those where the graphics are not needed, and cache does not help: files are updated with the release.
A separate story is substitutions during content updates. An editor takes a file from a shared folder by a similar name, and instead of the needed icon, a different one appears in the block, with a different meaning and color. The error surfaces on an already published page. We look at how this is closed at the level of graphics preparation and the rules for connecting it.
What a unified vector graphics set provides: speed and consistency
A unified vector graphics set starts with each icon living in a single source and a single format. While assets remain scattered images, the page pulls dozens of separate requests, and the weight and style of each icon depend on who prepared it and when. What changes when graphics are assembled into a system:
- Loading speed. Icons go into a common set and are served in one request instead of dozens — the weight of graphics on a typical page drops severalfold, and time to first render is reduced by hundreds of milliseconds.
- Interface consistency. A common grid, uniform stroke width and corner radii: icons in the header, buttons, and tables do not diverge in style, even if different designers drew them.
- Image optimization. Hidden layers, unnecessary groups, and metadata are removed from files — an individual icon loses 40-60% of its weight with no visible difference.
- Recoloring without a second file version. Color is inherited from text, so dark theme, hover, and disabled states work without a separate image for each state.
- Design system. Mockups in Figma and code come from a single source: new pages are assembled from ready-made elements, and adding a section takes hours, not days.
- Predictable behavior. Sizes 16, 24, and 32 scale without loss of sharpness, the interface does not "float" on high-density screens, and new icons are added using a ready-made template.
Methods of connecting graphics: comparison of approaches and limitations
The method of connecting graphics affects render time, the amount of markup, and how labor-intensive it is to replace one icon in the next release.
The choice is almost always a compromise: one option is more economical on weak devices, another is more convenient to maintain, and a third is found only in legacy templates. Below are real options for connecting icons and where each starts to get in the way.
| Option | When it fits | Limitations |
|---|---|---|
| Inline graphics | The icon changes color and state through styles | Markup grows, repetitions are duplicated, and it is not cached separately |
| Sprite sheet as a single file | Many similar icons, a single source is needed | An update resets the entire cache, does not work when opening the page locally |
| Icon font | Scaling like text and inheritance of typography are needed | Breaks when fonts are disabled or substituted, symbols are not readable by accessibility tools |
| Individual files in a vector set | Point replacements, different styles | Color is set inside the file, the number of server requests grows |
| Raster assets | Complex graphics with detail | Does not scale without loss of quality, weight multiplies for each resolution |
How we choose
A vector set is assembled once and reused, so stability of the result matters more than the insertion method itself.
Browser support has stopped being a blocking factor, but has not disappeared: built-in browsers in mobile shells and older engines handle external sprites and masks differently.
Therefore, we check the set on devices from the client's audience, not only in developer tools: IcoMoon and similar builders speed up preparation, but do not remove this check.
How we prepare and implement graphic assets: stages of work
Graphics on a site are usually fixed after the fact: icons come from different sets, some have no source files, and a new screen breaks an already approved style. We run asset preparation as an engineering process with a verifiable result at each step.
- Graphics audit. We compile a list of all SVG icons and images by pages and templates: source, duplicates, unused items, broken links. The output is a table showing what we delete, what we redraw, and what we transfer as is.
- Set scheme. We divide graphics into categories — interface icons, illustrations, logos — set a uniform style of strokes and corner radii, and define file naming rules. A new icon fits into the set without arguments about its name.
- Unified grid. We bring everything to a common modular grid, identical padding, and reference lines. Icons stop "jumping" in buttons and lists when the size changes.
- Asset preparation. We clean markup of unnecessary nodes, hidden layers, and editor metadata, merge repeating shapes, and make color inheritable from text — dark theme works without a second file.
- Implementation. We connect the set through interface components, replace old images, and define states: normal, active, disabled.
- Device testing. Real screens and browsers, dark theme, increased pixel density, text scaling, and printing; the build is checked for broken links in graphics.
- Documentation handover. Source files, the set scheme, a regulation for "how to add a new icon," and an acceptance checklist so that edits do not destroy the system.
The output is not a folder with images, but a set, a scheme, and rules: a new screen is assembled from ready-made elements.
What we hand over: source files, sets, and working rules
Handover is not an archive with images, but a working kit that your team uses to add new signs without us. Below is what remains with you after delivery: the structure of source files, assembled sets for different scenarios, and the rules by which graphics live on.
- Source file structure: directories by site section, inside — monochrome and color signs separately, vector in a unified size grid, and working layers for edits.
- Assembled sets: a sprite for the interface, individual files for lazy loading, versions for light and dark themes, normal and active states.
- Naming rules: purpose prefix, uniform case, size in the name — the name immediately shows where the sign is used and what size it is.
- Team instructions: a step-by-step procedure for adding a new sign, requirements for curves and fills, and a pre-publication check checklist.
- Usage map: a "sign — section — scenario" table so that when reworking a mockup you can see what can be changed freely and what is tied to other elements.
- Optimization and checking: a script that removes unnecessary nodes and metadata, and a check that after editing no sign has lost its size.
- Sources and rights: a list of source libraries with licenses so that the set does not retain signs of unclear origin.
Case: an SVG icon set removed desynchronization between sections
A service with a personal account came to us: six sections and more than forty pages that different teams had assembled at different times.
Icons came from three sources — some were drawn by a designer for a specific page, some remained from an old mockup, and some were brought by a contractor as ready-made raster images.
The audit showed the scale: the set had 47 files, 12 of which were duplicates of the same action with different stroke widths and corner radii. The search icon appeared in three variants, the cart in two.
Editing one icon took a designer up to half an hour: it was necessary to find all copies, update each one, and send the developer a list of changed files.
What we did
We assembled a common library in Figma with a single source: one grid, identical stroke width, color set as an inherited value rather than hard-coded in the file. Developers connected the set as inline SVG and a sprite — instead of raster copies for each theme.
The rules were fixed in a short document: how to add a new icon, which sizes are allowed, and what to do with the old one when replacing.
Result
The set was reduced to 38 files without loss of meaning — duplicates were removed, and disputed icons were redrawn once. Editing takes minutes: one source changes, and the other sections pick up the change; desynchronization between them is gone.
The release time for a new page was reduced by about half — graphics stopped being a separate approval stage. The weight of graphics on pages dropped severalfold because instead of a dozen raster files, one set is loaded. Changing the interface color now costs an edit in one place, not redrawing every icon.
How does font-based graphics differ from a vector set?
A font set keeps all signs in one file: each icon is a separate character in a service area of the encoding, and size, color, and alignment are set like text.
This is advantageous in terms of the number of requests — the browser fetches the file once and then serves signs from cache, so on pages with dozens of similar pictograms this option looks economical.
Limitations appear at the maintenance stage.
A sign in a font is single-color by definition: multicolor logos and gradients cannot be put into it, adding one sign requires rebuilding the entire file, and character mapping easily breaks when branches are merged — two developers assign one code to two different icons and get a substitution on the page.
Screen readers read such a character as a meaningless letter, so each output has to be manually given a hidden label.
A vector set consists of standalone files or a common sprite: a sign is inserted into markup as an element and styled like regular graphics — it takes the text color, hover state, animation, and multicolor fill.
One icon can be replaced without rebuilding the rest, and unused signs do not enter the build, so the set remains exactly what the page needs.
The choice of solution comes down to three questions: how many signs are required, can they be colored, and how often are new ones added.
Font signs are justified in a narrow niche — monochrome pictograms in emails where external files are not loaded, or in legacy builds that are not planned to be developed.
For an interface that lives and changes, a vector set provides predictable graphics maintenance: editing one icon does not turn into rebuilding a font, while theme, states, and accessibility remain under the team's control.
Technical concerns about graphics: implementation and maintenance
Concerns about graphics repeat from project to project: will rendering drift on different screens, what to do with already laid-out pages, who updates the set after delivery, and will edits break the interface. We answer five questions most often asked before the start.
Why does an icon look blurry on some screens?
More often the issue is not the format, but fractional coordinates and thin strokes that scaling blurs. We align contours to an integer grid and connect the vector directly — on high-density screens the contour remains sharp.
What will happen to the existing layout?
First, an inventory: where icons are connected, which ones duplicate each other. Replacement proceeds page by page, old files live until checking — rollback comes down to removing one connection.
Who updates graphics after launch?
We hand over source files and rules: how to add an icon, which checks run automatically. Your team adds simple elements itself; we get involved in complex cases.
How is interface accessibility addressed?
We hide decorative icons from assistive technologies; meaningful ones receive a text description. We check contrast in light and dark themes, and the focus state remains visible.
How to update the set without regressions?
We keep reference pages and compare rendering before and after edits at key resolutions. Changes go in a separate branch — divergence is visible before deployment, not on the live site.
Let's discuss your task for graphic assets for the site
To come back with a project estimate rather than general words, we need a short input: a link to the site or repository, source mockups, and two or three examples of icons that currently raise questions.
This is enough to understand the scope of the set, the state of the source files, and which blocks will need to be re-laid out.
- Review of the current state. We look at how graphics are connected now: individual files, sprite, icon font, or raster copies. We find duplicates, multicolor versions of the same symbol, and places where an icon breaks the grid.
- Comparison with mockups. We compare what is drawn with what is actually in the layout and record discrepancies: different stroke width, broken proportions, lost hover states.
- Storage and delivery format. We propose a scheme: a single sprite or individual files, color management through inheritance, a separate layer for small sizes.
- Work plan. We break the task into stages with a clear result for each: set preparation, cleanup, assembly, embedding, responsive testing.
- Project estimate. We state labor costs by stage and boundaries: what is included in the set, and what we handle as a separate task.
- Order of actions. We agree on priority — first what the user sees on the first screen, then secondary sections and states.
- Start of work and handover. After approval, we begin with the most loaded section so that the result is visible early, not at the end.
If you want to align expectations before the start — let's discuss the task: we will show how a set usually looks after cleanup and what changes in maintenance. Describe your situation, and we will come back with an estimate and work plan.
