Website icon style guide checklist for consistent UI icons

Website icon style guide checklist for a consistent UI

A website icon style guide checklist is the single most useful artifact a product team can build when icons start to drift across screens, components, and contributors. The day an interface passes five or six distinct icon sets is usually the day designers notice that the close glyph on a modal is heavier than the one inside a list row, that the search icon is 20 pixels in one component and 18 in another, and that stroke weights break on small sizes. A checklist makes those decisions before the first screen ships, and it gives engineers, contractors, and new hires a single reference to follow.

This guide is built for working product teams, not museums. It walks through the practical sections every website icon style guide checklist should cover: purpose, grid, sizing, stroke, corner radius, color, naming, states, and governance. Each section ends with the exact checks you can copy into your own document.

Why a dedicated icon checklist is worth the time

Icons are small, so they look easy. In practice, a UI without a style guide accumulates visual debt faster than almost any other layer of the interface. Three reasons make a checklist specifically valuable for icons:

• Icons live in every component. Buttons, list rows, breadcrumbs, navigation, alerts, tooltips, and empty states all reuse the same handful of glyphs. Small inconsistencies are visible at every touchpoint.
• Icons are touched by many hands. Designers, engineers, contractors, and content editors all import, export, and resize them. A written rule prevents every person from reinterpreting the system.
• Icons break at small sizes faster than at large ones. A 24 pixel glyph has room for forgiveness. A 16 pixel glyph exposes every corner and stroke mistake. A checklist sets the rules for the hardest case first.

The aim is not a perfect document. The aim is a working contract that survives contact with real product deadlines. Treat the checklist as a living page in your design system, not a one-off PDF handed to a vendor.

How to use this website icon style guide checklist

Work through the sections in order if you are starting from scratch. If you already have a partial library, run an audit first, then come back to the sections where the audit revealed gaps. The checklist is structured so each decision reduces the number of decisions the next contributor has to make.

1. Define the purpose of the library and the surfaces it will cover.
2. Lock the grid and base size before drawing any glyphs.
3. Set the stroke, corner radius, and fill rules for each size tier.
4. Decide the color tokens and contrast expectations.
5. Write a naming convention and folder structure.
6. Document states, animations, and accessibility behaviour.
7. Assign ownership, versioning, and review cadence.

Most teams try to skip step 2 and end up redrawing icons to fit a grid they never agreed on. The grid is the most leveraged decision in the whole checklist.

Section 1: purpose, scope, and ownership

Open the document with a short paragraph that answers four questions. If a new contributor cannot answer these in under a minute, the introduction needs work.

• What is this library for? Product icons only, or marketing and product combined.
• Where will these icons appear? Web app, marketing site, mobile, email, documentation.
• Who owns the library? A design system team, a brand team, or a single designer.
• What is out of scope? Logos, illustrations, decorative graphics, and avatars are usually excluded.

Scope drives every other choice. A product-only library can be ruthlessly functional. A marketing-shared library has to balance the brand voice with UI legibility. Writing scope down stops the library from quietly absorbing assets it was never meant to own.

Section 2: grid, base size, and keyline shapes

The grid is the most important technical decision in any website icon style guide checklist. Pick a base canvas, draw a keyline set, and commit to it before any drawing happens.

Element	Recommended value	Why it matters
Base canvas	24 by 24 unit grid for product UI	Matches Material, Carbon, and most modern design systems, so cross-system learning is easier.
Keyline shapes	Square, circle, rectangle, freeform	Set a square safe area, a circle for circular icons, and a rectangle for horizontal glyphs like sliders.
Padding	1 unit around the keyline shape	Gives optical breathing room when icons are placed inside 24, 32, or 40 pixel slots.
Pixel snapping	Whole pixels on 24 grid, half pixels on retina	Prevents blurry edges on common display densities.

If your product targets mobile, add a 20 unit base canvas as a companion. The 24 grid remains the source of truth, and the 20 canvas is a sized export for compact mobile UI.

Section 3: sizing system and size tiers

Icons need to render at multiple sizes without redrawing. The simplest approach is a fixed set of size tiers, each with a clear role. Avoid the temptation to support every pixel size from 10 to 64; that creates a library with no real rules.

Size tier	Pixel size	Typical use	Notes
Compact	16 by 16	Inline with body text, dense tables, breadcrumbs	Reduce stroke weight by 0.5 unit to prevent muddy pixels.
Default	20 by 20	List rows, form fields, secondary buttons	Most product icons live at this size.
Standard	24 by 24	Primary buttons, navigation, toolbars	The base canvas size.
Emphasis	32 by 32	Empty states, feature highlights, cards	Same shapes, slightly thicker perceived weight.
Hero	48 by 48 and above	Onboarding, marketing modules, dashboards	Consider redrawing rather than scaling up to avoid fat endpoints.

The 20, 24, and 32 tiers usually cover 90 percent of a product interface. The 16 tier handles dense surfaces. Anything above 48 should be reviewed because icons are starting to behave like illustrations, and the same rules no longer apply.

Section 4: stroke, weight, and corner radius

Stroke weight is where most icon libraries drift. Designers choose 1.5 on a 24 grid because it looks balanced in a hero component, then ship the same icon at 16 where that weight is now visually heavy. The fix is to define stroke behavior at each size tier instead of one rule for all.

• Choose stroke or fill first. Stroke-led sets feel lighter and are easier to redraw. Fill-led sets feel more graphic and need careful balance to avoid over-weighting small sizes.
• Set stroke weight by tier. For a 24 grid, 1.5 is a common default. At 16, drop to 1 or 1.25. At 32, hold at 1.5 or raise to 2.
• Pick an endcap and join style. Round caps and round joins feel friendly and forgiving. Butt caps and miter joins feel technical and reveal errors faster. Pick one and apply it everywhere.
• Standardize corner radius. A single radius value, such as 1 or 2 units on a 24 grid, keeps square glyphs consistent. Avoid mixing sharp and soft corners across similar concepts.

If the library mixes both stroke and fill icons, write a rule for when each is used. Many teams reserve fill for navigation states such as selected, active, or filled heart, and use stroke for everything else.

Section 5: color, contrast, and theming

Icons inherit color from the surface they sit on, but the style guide should still set expectations. A useful rule of thumb is to treat icons as text, not as graphics.

Surface	Default icon color	Allowed variants
Default content	Primary text color token	Muted or disabled for state changes
Inverse surface	Primary inverse text color token	Brand accent for emphasis
Brand surface	White or inverse text token	Decorative accents only when paired with text
Status	Success, warning, error, info tokens	Used only with paired labels or tooltips

Contrast is the part most checklists miss. The Web Content Accessibility Guidelines set a baseline of 3 to 1 for non-text UI elements, which includes icons. A small table in the style guide that lists the minimum contrast for each named surface prevents the team from shipping low-contrast decorative icons by accident.

Section 6: states and interactivity

Icons that behave like controls need rules for their behavior. A search icon, a chevron, and a heart all carry meaning that changes with state, and a checklist should describe how that state is communicated.

• Default, hover, focus, active, disabled. Define a behavior for each. Many teams use color and fill changes for state, leaving shape untouched so the icon stays recognizable.
• Selected and unselected. For navigation, write a rule for which icons get a fill variant and which rely on a color change only.
• Loading and progress. Decide whether to swap a static icon for an animated one, or to keep the static glyph and add a separate spinner.
• Error and warning. Reserve the warning triangle and error circle for status messaging only. Reusing them in unrelated contexts confuses users.

Section 7: naming convention and file structure

Names travel further than any visual decision. A consistent naming convention is what makes the library searchable three years from now when the original designer has moved on.

• Use a stable prefix. Something like icon- in the design tool and Icon in the component library, so the team can filter instantly.
• Describe the concept, not the visual. icon-search survives redesigns. icon-magnifier breaks the day the team switches to a different metaphor.
• Add state suffixes only when needed. icon-heart-filled and icon-heart-outline are clearer than icon-heart plus an internal style swap.
• Group by domain, not by visual style. A folder for navigation, a folder for status, a folder for content actions. New contributors find what they need faster.

Match naming to the same convention used in your broader design system, especially if you already publish component documentation. Consistent naming across icons, components, and tokens saves a surprising amount of time in code review.

Section 8: accessibility and localization

Icons are not text, and a checklist should treat them as such. The accessibility section often hides inside a separate document, but it deserves its own place in the icon guide because the answers are specific to icons.

• Decorative icons need aria-hidden. If the icon sits next to a label, the label is the accessible name and the icon is purely visual.
• Functional icons need a label. A button whose only content is an icon needs an accessible name, usually through aria-label or visually hidden text.
• Status icons need a paired message. An error triangle should not be the only signal. Pair it with text or aria-live content for screen readers.
• Test in context, not in isolation. A 16 pixel chevron that looks fine in a Figma preview can disappear inside a dropdown. The style guide should encourage testing the smallest, darkest, and busiest variants.

For teams shipping in multiple languages, write a rule for icons that imply text concepts. A checkmark usually works in most cultures. An inbox icon has cultural variation. A right-facing arrow implies forward in Latin-reading languages and the opposite in Arabic-reading ones. The checklist should call this out so the team plans for bidi support early.

Section 9: handoff, exports, and engineering

Most icon libraries break at handoff, not at design. The fix is to make the export step part of the design system rather than a per-project decision.

Step	Design output	Engineering output
Source	Vector master file on a 24 grid	SVG component with currentColor
Exports	SVG per size tier	React, Vue, or framework component with size prop
Tokens	Color and size tokens	CSS variables or design token package
Documentation	Style guide page per icon	Generated docs from component props

Using currentColor in SVG exports is the single most useful handoff decision. It lets the same icon pick up any text color token in CSS without a per-color variant. Pair this with a documented set of color tokens and the engineering team stops asking designers for new exports every sprint.

Section 10: governance, versioning, and audits

A website icon style guide checklist without governance is a wish list. The last section of the guide should describe how the library is maintained, how changes are reviewed, and how often the team audits for drift.

• Versioning. Use semantic versioning for the icon package, even if it is internal. Breaking changes should require a major bump and a migration note.
• Proposal process. A short proposal template, including use case, surfaces, and alternative icons, prevents a flood of one-off requests.
• Review cadence. A monthly review of new icon requests and a quarterly audit of the existing library keeps the system honest.
• Deprecation policy. When an icon is replaced, keep the old one available for at least one release cycle and document the swap in the changelog.

A compact checklist you can copy into your guide

Once the long-form sections are written, distill them into a one-page checklist. The condensed version is the page most contributors will actually use.

• Scope and ownership are defined in the first paragraph.
• Base canvas is set to a 24 by 24 grid with a documented keyline set.
• Size tiers are limited to a small set such as 16, 20, 24, 32, and 48.
• Stroke weight, endcaps, and corner radius are documented per size tier.
• Color and contrast expectations reference the design tokens, not hard values.
• State behavior is defined for default, hover, focus, active, disabled, and selected.
• Naming convention is concept-first, with consistent prefixes and suffixes.
• Accessibility rules cover decorative, functional, and status icons.
• Engineering handoff uses SVG with currentColor and a documented size prop.
• Governance section names the owner, the review cadence, and the deprecation policy.

Common mistakes the checklist should prevent

Even good teams repeat the same icon mistakes. Call them out in the guide so the next contributor avoids the same trap.

• Mixing stroke and fill inside the same conceptual group. The heart should not appear as an outline in one place and a filled shape in another without a state reason.
• Designing at 24 and shipping at 16 without checking. The smallest tier is the hardest. Design from the smallest size up, not the largest down.
• Using brand color for every status icon. Reserve brand color for emphasis, and use the status tokens for success, warning, and error.
• Skipping the disabled state. Disabled icons that keep full color and opacity look broken. Document the reduced opacity or muted color token in advance.

Where this fits in a broader design system

Icons rarely stand alone. They sit next to typography, share color tokens with text, and appear inside components. A useful website icon style guide checklist references the surrounding system rather than redefining it. If the design system already documents type, color, and spacing, link to those pages instead of duplicating values. The icon guide then becomes a small, focused document that adds the rules specific to icons.

If you are building the wider system at the same time, treat the icon guide as a pilot. A successful icon system is a good signal that the design system approach is working, and it gives the team a smaller surface to learn the publishing and versioning workflow before tackling larger areas like components and patterns.

Reviewing an existing library against the checklist

For teams that already have a library, run a structured audit before rewriting anything. The audit turns vague complaints into specific gaps you can fix in priority order.

1. Export every icon at 16, 20, 24, and 32 pixel sizes onto a contact sheet.
2. Tag each icon with the current stroke weight, corner radius, and color usage.
3. Mark icons that drift from the dominant value, then cluster the drift by reason.
4. List icons that are missing for common concepts in your product.
5. Prioritize fixes by the surfaces where the drift is most visible.

A typical audit reveals two or three systemic issues rather than dozens of one-off fixes. Fixing stroke weight, for example, will realign a large number of icons in one pass.

Final reminder before publishing the guide

A good website icon style guide checklist is short enough to read in fifteen minutes and specific enough to answer the next designer’s actual question. If the document is over fifty pages, contributors will stop reading and the drift will return. If the document is one page, it will not survive the first difficult edge case. Aim for a focused guide that covers the decisions above and links out to the broader design system for everything else. Pair it with a living contact sheet so the rules can be checked against the real library, and review the contact sheet on the cadence your governance section promises.

Frequently asked questions

What should a website icon style guide checklist include at minimum?

A website icon style guide checklist should at minimum cover purpose and scope, the base grid and keyline shapes, size tiers, stroke and corner rules, color and contrast expectations, naming conventions, accessibility, and a governance section. Those eight areas are enough to keep a library consistent for most product teams.

What is the best base canvas size for a product icon set?

A 24 by 24 unit grid is the most common base canvas for product UI because it matches most modern design systems and works well at the standard 24 pixel size. A 20 unit grid is a reasonable alternative for mobile-first products. Pick one and stay consistent.

How many size tiers should an icon library support?

Most libraries need only four or five tiers. A typical set is 16, 20, 24, 32, and 48 pixels. Adding more tiers increases the maintenance cost without a clear benefit, because contributors can almost always use the closest tier instead of a custom size.

Should icons use stroke or fill by default?

Stroke-led sets are easier to maintain and feel lighter on dense UI. Fill-led sets feel more graphic and need careful weight management. Many teams use stroke as the default and reserve fill for selected or active states. The style guide should document which approach is used and when.

How do you keep stroke weights consistent across sizes?

Define a stroke weight per size tier rather than one rule for all sizes. On a 24 grid, 1.5 units is a common default, but the 16 tier usually needs a lighter weight such as 1 unit to avoid looking heavy. Document each weight in the style guide and audit the library against those values.

How should icons handle dark mode and theming?

Build icons with currentColor so they inherit the surrounding text color. Theme the icons by changing the text color token on the surface. Hard-coding colors into SVG files breaks theming and is a common reason for icon drift between light and dark interfaces.

What is the right contrast ratio for UI icons?

For non-text UI elements including icons, a contrast ratio of at least 3 to 1 against the adjacent surface is the standard most teams aim for. For status icons that carry meaning without paired text, consider a higher ratio of 4.5 to 1 to match body text contrast.

How do you name icons in a scalable way?

Use a stable prefix, describe the concept rather than the visual, and add state suffixes only when needed. For example, icon-search is more durable than icon-magnifier, and icon-heart-filled is clearer than relying on an internal style swap.

How do you handle icons that imply cultural concepts?

Document the cultural assumption in the style guide and provide alternatives for major markets. A right-facing arrow, an inbox icon, and a paperclip each carry cultural weight. Either keep them consistent across markets or design locale-specific variants and document when to use each.

How often should an icon library be audited?

Run a quick visual audit every quarter and a deeper review every year. Quarterly audits catch drift introduced by new contributors, and yearly reviews catch the systemic issues that build up over time. Each audit should result in a small set of documented fixes rather than a full rebuild.

Related reading

• Instant gaming: what it is and how it works in 2026
• Peak design thinking: how creative teams turn strong ideas into work that ships