UI Icon Size Guide: Standard Pixels, Stroke Weights, and Export Rules

Overview

This article is a working reference for teams and solo designers who need reliable UI icon sizes without reinventing the process every time. Instead of treating icon design as a collection of one-off files, it helps to think of icons as a system: one base grid, a limited set of target sizes, predictable stroke settings, and repeatable export rules.

The safest evergreen principle is this: there is rarely one universal icon size for every interface, but there are common sizes that cover most design workflows well. For product UI, the most common small sizes are 16px, 20px, 24px, 32px, and 48px. These usually map well to dense desktop interfaces, standard web UI, touch-friendly controls, and larger feature illustrations or app surfaces. For Apple platforms, source guidance shows that interface icons are often prepared in families such as 16px and 32px, 32px and 64px, 128px and 256px, and 256px and 512px for higher-density rendering. The exact size may vary by context, but consistency inside the product matters more than chasing a mythical perfect number.

For app icons, platform rules are more specific than for small interface symbols. Source material on iOS notes common iPhone app icon outputs such as 120×120 for Home Screen at @2x and 180×180 at @3x, plus additional sizes for Spotlight, Settings, and notifications. A helpful detail from the same source: for iOS Settings icons, designers should avoid adding their own extra border or overlay because the system applies a subtle stroke treatment automatically for visibility on white backgrounds.

For everyday UI icon sets, three rules stay useful across tools and platforms:

• Design on a consistent base grid, usually 24px or 20px for general UI libraries.
• Use a controlled stroke scale that changes only at set size jumps.
• Export from master vectors into a small, documented list of output sizes and formats.

If you also manage downloadable design assets, this same discipline improves reusability. A clean icon library becomes easier to bundle with templates, product kits, and other graphic design assets because every file has a clear use case, naming rule, and format.

Step-by-step workflow

Here is a process you can reuse for web products, mobile apps, and asset libraries.

1. Start with use cases before you start drawing

List where the icons will actually appear. Typical categories include:

• Dense navigation or data tables
• Form controls and buttons
• Toolbar actions
• Status and alert symbols
• Marketing UI previews or presentation decks
• App launcher or store icons

This matters because a 16px icon for a table action has different needs than a 48px icon used in onboarding or feature cards. If the icon will appear in more than one place, decide whether you need a single scalable shape or separate optimized versions for small and large sizes.

2. Choose a base icon grid

For most UI icon systems, a 24px artboard is the most flexible starting point. It is large enough for readable geometry and easy to scale down to 20px or 16px when needed. A 20px grid can also work well for compact product interfaces. Use 32px or 48px grids for larger utility icons, onboarding visuals, or settings sections.

A practical standard set looks like this:

• 16px: compact desktop UI, tables, dense toolbars
• 20px: modern web app controls and medium-density interfaces
• 24px: default base size for general UI icon libraries
• 32px: larger controls, settings panels, empty states
• 48px: feature tiles, onboarding, app-level graphic accents

If your team only supports one base master, choose 24px. It is the safest center point.

3. Define live area and padding

Not every icon should fill the entire artboard. A common mistake is drawing every shape edge to edge, which makes icons feel cramped and inconsistent. Instead, define an inner live area. On a 24px grid, many systems keep the main shape inside roughly 20px, leaving a small outer buffer. Circles, diagonals, and arrows often need optical adjustments, but the principle stays the same: icons should look equally weighted, not equally measured.

When building reusable creative assets, document whether your icons are:

• Full-bleed inside the artboard
• Contained inside an inner safe area
• Optically balanced with exceptions for curves and diagonals

This single note prevents endless revisions later.

4. Set stroke widths by size tier

Stroke is where many icon sets become visually uneven. If the stroke is too thin, the icon disappears at small sizes. Too thick, and detailed shapes clog up quickly. A useful evergreen approach is to define stroke width by size band rather than by individual icon.

Try this starting framework:

• 16px icons: around 1.5px strokes, or simplified filled versions if strokes break down
• 20px to 24px icons: 1.5px to 2px strokes
• 32px icons: 2px strokes usually read well
• 48px icons: 2px to 2.5px depending on detail level

The exact number depends on the style, but the key is not to mix arbitrary weights. Keep corner radius, end caps, joins, and stroke alignment consistent too. If your tools allow center-aligned strokes only, preview exports carefully because apparent thickness can shift when rasterized.

For very small UI icon sizes, consider reducing detail before reducing stroke. A simpler icon with fewer shapes nearly always performs better at 16px than a fully faithful miniature of the 24px version.

5. Snap to pixels deliberately

Icons for digital interfaces should look crisp, which means vectors need to be aligned with raster output in mind. This is especially important for SVG and PNG exports used in product interfaces. Horizontal and vertical strokes often render best when their paths align predictably on the pixel grid. Half-pixel positioning may be necessary depending on stroke width and export behavior, but the rule is not “never use half pixels.” The real rule is “export and inspect the result.”

Test at real size, not zoomed in at 800%. A blurry 1px line or soft corner usually points to misalignment or an overcomplicated shape.

6. Separate interface icons from app icons

Small UI icons and app icons are different jobs. Interface icons prioritize clarity inside the product. App icons must satisfy platform-specific output requirements and visual conventions. Based on the source material, iOS app icons commonly require different sizes for Home Screen, Spotlight, Settings, and notifications, with @2x and @3x variants on iPhone. iPadOS follows similar logic. Build these separately rather than assuming one export preset will handle both product UI and launcher assets.

If you are packaging premium design resources or downloadable design assets, label these categories clearly so users know whether a file is for interface use, app store submission, or marketing mockups.

7. Export from one master source

Keep one editable master per icon style, then automate exports. Good output sets often include:

• SVG: best for web UI and scalable product use
• PNG: useful for presentations, docs, and quick placements
• PDF or platform vector format: useful in some app workflows

Name files consistently. A simple pattern works well:

icon-name_style_size_state.format

Example:

search_outline_24_default.svg

For mirrored or directional icons, include that too:

arrow-left_outline_20.svg

This becomes especially important when sharing icon libraries with marketers, product managers, or developers who need fast retrieval without opening every file.

Tools and handoffs

The right workflow is less about a specific app and more about making handoff predictable. Whether you design in Figma, Illustrator, Sketch, or another vector tool, your team should agree on the same decisions: master grid, stroke scale, naming, export formats, and versioning.

Designer to developer handoff

For product teams, handoff should include more than the raw SVG. Provide:

• Icon name and intended meaning
• Default size and any supported alternate sizes
• Stroke or fill style
• Bounding box or padding rule
• Color behavior, such as currentColor for web
• Any exceptions, like filled variants for 16px use

Developers usually need to know whether icons are decorative, interactive, or semantic. That affects implementation and accessibility labeling. Even if accessibility details are handled elsewhere, the icon inventory should make meaning unambiguous.

Asset library management

If you publish or maintain icon-related creative assets, organize the set as a product, not a folder dump. Group by category, state, and platform relevance. For example:

• Navigation
• Media controls
• Commerce
• Files and folders
• Status and alerts
• Brand and social

This is also where related resources can help users build faster. If readers are sourcing companion files such as free SVG icons, template packs, or other UI-ready design assets, point them toward curated references like Best Free SVG Icon Sites for Commercial Use.

Using icons inside wider brand systems

Icons rarely live alone. They appear inside websites, slide decks, posters, social graphics, and mockups. That is why a disciplined icon system supports other graphic design assets too. A brand team using consistent icons in pitch decks, product screenshots, and marketing visuals creates stronger recognition than one switching between mismatched packs every month.

If you are extending icon work into larger visual systems, it can help to study how consistent design language carries across formats. For adjacent inspiration on broader visual identity and layout thinking, see Concrete Confidence: How Gangnam Brutalism Shapes Modern Minimal Brand Identity.

Quality checks

Before shipping any icon set, run a short review. This stage catches more issues than endless redrawing.

Check 1: Compare icons at real UI size

Place ten to twenty icons side by side at 16px, 20px, 24px, and 32px. Ask:

• Do they feel equally weighted?
• Are any shapes too busy?
• Do circles, squares, and diagonals look balanced?
• Are line endings and corners consistent?

An icon can look perfect on its own and still feel wrong inside a set.

Check 2: Test light and dark backgrounds

Thin strokes and open counters may disappear on dark surfaces. Filled icons may feel too heavy on light ones. Review both. If one style fails repeatedly, create a deliberate alternate rather than forcing one file to do everything.

Check 3: Export and inspect actual files

Do not assume the vector preview matches the exported result. Open SVGs in a browser. Inspect PNGs at 100%. Verify that strokes remain crisp and that no unexpected clipping or scaling issues appear.

Check 4: Validate platform-specific outputs

For app icons, check the latest platform documentation before release. The source material makes clear that Apple platform outputs can include multiple sizes for different placements and density scales, and those needs may change over time. The evergreen habit is simple: verify launcher and system icon requirements at the moment you prepare release assets, even if your interface icon system has not changed.

Check 5: Remove unnecessary detail

If an icon needs labels or tooltips to make sense, that may be normal. If it only works when enlarged, simplify it. At small sizes, clarity beats cleverness every time.

Check 6: Audit naming and packaging

Messy file names make even strong premium design resources hard to use. Before delivery, confirm that naming is clear, duplicate exports are removed, and obsolete drafts are not mixed into the final package.

When to revisit

The best icon size guide is not static. It should be reviewed whenever the interface, platform, or tooling changes enough to affect clarity or output.

Revisit your icon rules when:

• You adopt a new design tool or export plugin
• Your product adds a new density tier, theme, or device context
• You shift from outline to filled icons, or vice versa
• Platform guidance changes for app icon dimensions or system rendering
• Your team adds contributors and needs stricter library governance
• You notice recurring developer fixes after handoff

A practical maintenance routine is to keep a short icon spec document with five items: supported sizes, stroke scale, live area, export formats, and naming. Review it quarterly or whenever release workflows change. Then test a small sample library before updating everything.

If you want a simple action plan, use this one:

1. Pick one master size, ideally 24px, for your editable source files.
2. Support a short list of outputs: 16px, 20px, 24px, 32px, and 48px where needed.
3. Define stroke rules by size band and stop making per-icon exceptions.
4. Separate app icon production from interface icon production.
5. Export from a single source of truth and inspect real outputs before shipping.
6. Recheck platform-specific app icon dimensions at release time.

That workflow keeps your UI icon sizes predictable, your handoffs smoother, and your downloadable creative assets easier to maintain. And because icon standards do shift with platforms and tools, this is the kind of reference worth returning to whenever your system changes.