Why icons are drawn on a 24 × 24 grid

Open an SVG from many popular icon sets and it starts the same way: viewBox="0 0 24 24". Material Design's system icons, Feather, Lucide, the Heroicons outline set and the Web3 Icons artwork all use it. The number isn't magic, but it isn't arbitrary either.

Knowing why 24 works also tells you where it doesn't. Drawn on 24 units and shown at 16 or 20 px, an icon lands on fractional pixels, and that's where crisp icons go soft. This guide explains the grid, shows exactly how it maps to common sizes, and covers when another grid is the better choice.

Where 24 comes from

A few practical reasons stack up behind it.

It matches a line of text. Interface body text is usually 14 to 16 px with a line height around 20 to 24 px. A 24 px icon occupies about one line, which suits toolbars, list rows and buttons.

It survives density scaling. Android's dp and Apple's points made designers think in 1x units that multiply out to 2x and 3x screens. A 24-unit icon becomes 48 and 72 device pixels, both whole numbers.

It divides well. 24 divides evenly by 2, 3, 4, 6, 8 and 12, so halves, thirds and quarters of the canvas all fall on whole units. That makes centering, symmetry and evenly spaced elements easy. A 20-unit canvas has no clean thirds; a 16-unit canvas has no thirds or sixths.

It fits spacing systems. Many design systems space everything in multiples of 4 or 8 px. 24 is 6 × 4 and 3 × 8, so icons line up with the rest of the layout.

A big system standardized it. Material Design, introduced by Google in 2014, specified system icons at 24 by 24 dp with 2 units of padding around a 20 by 20 live area. Many open-source icon sets adopted the same canvas, and once tooling and component libraries assumed 24, the convention fed itself.

How 24 units map to real sizes

The grid is only pixel-exact when the rendered size is a whole multiple of 24. At other sizes each unit becomes a fraction of a pixel, and only some coordinates land on pixel boundaries.

Two things follow from this table. First, a 24-unit drawing is exact at 24 and 48 px and only approximate at 16, 20 and 32. Second, the multiples of 3 matter more than they look: an edge at 3, 6, 9, 12, 15, 18 or 21 lands on a whole pixel at 16, 24, 32, 40 and 48 px. A common 3-unit margin turns into exactly 2 px at 16 px and 4 px at 32 px.

You can check any coordinate with one line of arithmetic:

// Where does a coordinate on a 24-unit grid land at a given size?
const toPx = (unit, size, grid = 24) => (unit * size) / grid

toPx(3, 16)  // 2      edge falls on a pixel boundary
toPx(4, 16)  // 2.667  edge falls inside a pixel and blurs
toPx(12, 20) // 10     crisp
toPx(9, 20)  // 7.5    soft

On high-density screens, multiply by the device pixel ratio. A 16 px icon on a 2x screen has 32 device pixels, so it behaves like the 32 px row: multiples of 3 are still the safe coordinates. Pixel snapping goes into what happens to the edges in between.

Why draw on a grid at all

You could draw icons freehand at any size and export them. The grid exists for the set, not for the single icon.

• Predictable edges. If straight edges sit on whole units, you know where they'll land at each size instead of discovering blur after export.
• Shared proportions. When everyone uses the same canvas, padding and keylines, icons drawn months apart by different people still match in size and position.
• Comparable weights. A 2-unit stroke means the same thing in every file, so line icons look like they belong together.
• Interchangeable files. Every icon has the same viewBox, so code can swap one for another and only width and height control the rendered size. No icon needs its own offsets.

That last point matters a lot for crypto products, where an icon is often picked at runtime from a list of thousands. If every file shares one canvas and one margin, a token row never shifts when the token changes.

When another grid makes sense

24 is a good default, not a rule. Pick the grid that matches the size you render most.

20 units suit dense desktop interfaces where icons mostly appear at 20 px: sidebars, toolbars, compact tables. Drawn on 20, those icons are exact at 20 and 40 px. Heroicons, for example, ships a 20 px solid set alongside its 24 px sets.

16 units are for icons that live at 16 px: favicons, inline indicators, the small chain badge on a token icon. At that size you're placing individual pixels, so draw the 16 px version as its own artwork rather than shrinking a 24 drawing. Designing for 16px covers what to keep.

32 units or more suit marks shown mostly at 32 to 64 px, where detail can survive: app-icon-like tiles, asset headers, onboarding screens. A larger grid gives finer control over curves and thin parts.

Several optical sizes is the most thorough answer: draw the same icon separately for small and large use. Material Symbols, for example, has an optical size axis that runs from 20 to 48. That's realistic for your own interface icons. For third-party brand logos you usually can't redraw per size, so you pick one canvas, keep key edges on friendly coordinates where the mark allows, and accept a little softness at the in-between sizes.

Choosing for your own product

1. List the sizes icons actually render at. Check the CSS in production, not the mockups.
2. If one size clearly dominates, consider drawing on that size's grid.
3. If you render at a mix of 16, 24 and 32 px, use 24 and put important straight edges on multiples of 3.
4. If 16 px matters a lot, draw dedicated 16 px versions of your own icons.
5. Whatever you choose, keep one canvas and one margin across the whole set.