Where the Eight Point Grid Came From

Android scales a 48 by 48 pixel bitmap to six sizes: 36, 48, 72, 96, 144 and 192 pixels. Google's own documentation writes that out as a ratio, 3:4:6:8:12:16, and the ratio is the whole of the argument. Every one of those numbers is an integer. Nothing lands on a half pixel, nothing needs to be smeared across two rows of the panel, and the same drawing survives a 0.75x phone and a 4x phone without anyone touching it.

That is the constraint under the eight point grid. It is a real constraint, it is older than most of the people quoting it, and it has been quietly repeated for a decade in a form that does not quite survive the arithmetic. I have repeated it myself, in client documentation, with more confidence than the evidence supports. What follows is the constraint as it actually is, and the part of it that has expired.

The buckets

Android does not let you position anything in device pixels. The unit is the density-independent pixel, dp, which Google defines as "a virtual pixel unit that's roughly equal to one pixel on a medium-density screen (160 dpi, the 'baseline' density)". The conversion is a single multiplication:

px = dp * (dpi / 160)

px = dp * (dpi / 160)

px = dp * (dpi / 160)

The dpi in that formula is not the panel's measured dot pitch. It is the bucket the device has been assigned to. There are six of them, and they are the entire vocabulary:

Two of those factors are fractional: 0.75 and 1.5. Everything interesting follows from them. If every bucket were a whole number, any integer dp value would survive and there would be no grid convention at all. It is ldpi and hdpi that impose the discipline, and hdpi is the one that still ships.

What iOS actually does, which is not the same thing

Apple's model looks similar and is not. iOS gives you points rather than dp, and Apple's own drawing guide is blunt about the relationship: "One point does not necessarily correspond to one physical pixel." The coordinate space you draw into is logical. "The purpose of using points (and the logical coordinate system) is to provide a consistent size of output that is device independent." A scale factor connects the two, and Apple's guide says it plainly: "On a standard-resolution screen, the scale factor is typically 1.0. On a high-resolution screen, the scale factor is typically 2.0."

That is the @1x, @2x, @3x asset convention, and if the story stopped there iOS would be the clean case: integer factors only, nothing fractional, no reason for a grid unit at all. The story does not stop there.

Apple's archived iOS Device Compatibility Reference carries a screen geometry table with a column most designers have never looked at, called native scale factor. For the iPhone 7 Plus and iPhone 8 Plus the table gives a UIKit size of 414 by 736 points, a UIKit scale factor of 3.0, a native resolution of 1080 by 1920 pixels, and a native scale factor of 2.608. Those numbers do not reconcile, and Apple explains why they do not:

If the native scale differs from the UIKit scale factor, then iOS first renders the content at the UIKit scale factor and then downsamples it to fit on the screen.

Read that again with a grid in mind. On those devices the system lays out at 3x, producing a 1242 by 2208 pixel image, and then resamples the whole thing down to 1080 by 1920. The ratio is roughly 0.87. An 8 point margin becomes 24 pixels in the render and about 20.9 pixels on the glass. There is no value you can choose, on any grid, that lands on a whole device pixel after that step. Apple even warns about the cost: "For games and other apps that perform many calculations per pixel, rendering these additional pixels can be expensive."

I want to be careful here, because that archived table is internally inconsistent: the rows for the iPhone 6 Plus and 6s Plus list a UIKit size of 375 by 667 points alongside the same 2.608 native scale, which cannot be right for a 1080 by 1920 panel. The 414 by 736 figure on the 7 Plus and 8 Plus rows is the one that reconciles arithmetically, and it is the one I have used. That an official Apple reference disagrees with itself on this is itself worth knowing, and I have not found a corrected version.

The arithmetic, done properly

Now the claim itself. The convention says 8 because 8 divides cleanly where 5 or 7 do not. That is true. It is also true of 4, and this is the part that usually goes missing.

Run every candidate unit through the Android factors that matter, and through the iOS integer factors:

unit   0.75x   1.5x    2x    3x    4x    verdict
   1    0.75    1.5     2     3     4     fails at 0.75 and 1.5
   2    1.5     3       4     6     8     fails at 0.75
   3    2.25    4.5     6     9    12     fails at 0.75 and 1.5
   4    3       6       8    12    16     clean everywhere
   5    3.75    7.5    10    15    20     fails at 0.75 and 1.5
   6    4.5     9      12    18    24     fails at 0.75
   7    5.25   10.5    14    21    28     fails at 0.75 and 1.5
   8    6      12      16    24    32     clean everywhere
  10    7.5    15      20    30    40     fails at 0.75
  12    9      18      24    36    48     clean everywhere
  16   12      24      32    48    64     clean everywhere

unit   0.75x   1.5x    2x    3x    4x    verdict
   1    0.75    1.5     2     3     4     fails at 0.75 and 1.5
   2    1.5     3       4     6     8     fails at 0.75
   3    2.25    4.5     6     9    12     fails at 0.75 and 1.5
   4    3       6       8    12    16     clean everywhere
   5    3.75    7.5    10    15    20     fails at 0.75 and 1.5
   6    4.5     9      12    18    24     fails at 0.75
   7    5.25   10.5    14    21    28     fails at 0.75 and 1.5
   8    6      12      16    24    32     clean everywhere
  10    7.5    15      20    30    40     fails at 0.75
  12    9      18      24    36    48     clean everywhere
  16   12      24      32    48    64     clean everywhere

unit   0.75x   1.5x    2x    3x    4x    verdict
   1    0.75    1.5     2     3     4     fails at 0.75 and 1.5
   2    1.5     3       4     6     8     fails at 0.75
   3    2.25    4.5     6     9    12     fails at 0.75 and 1.5
   4    3       6       8    12    16     clean everywhere
   5    3.75    7.5    10    15    20     fails at 0.75 and 1.5
   6    4.5     9      12    18    24     fails at 0.75
   7    5.25   10.5    14    21    28     fails at 0.75 and 1.5
   8    6      12      16    24    32     clean everywhere
  10    7.5    15      20    30    40     fails at 0.75
  12    9      18      24    36    48     clean everywhere
  16   12      24      32    48    64     clean everywhere

Four is the smallest integer that survives every Android bucket. Eight survives, but it survives because it is a multiple of four, not because there is anything special about eight. The pixel argument, taken on its own terms, licenses a four point grid. It does not license an eight point grid. Every extra claim made for eight is an argument about something else: fewer decisions, coarser rhythm, a scale that is harder to fiddle with in a hurry.

The table also disposes of the ten point grid, which comes round every few years on the grounds that base ten is easier to hold in the head. Ten breaks at 0.75x, where eight does not. If you are going to invoke device pixels as your reason, ten is the one number you cannot choose.

The most careful version of the popular origin story I could find is Elliot Dahl's "Intro to the 8-Point Grid System", published on 14 December 2016 and updated the following June, which credits an earlier post by Bryn Jackson as the fuller treatment. Dahl's technical case is exactly the half pixel argument: "Scaling 5px by 1.5x will result in a half pixel offset." He is right about 5. The piece does not make the case that 8 is required rather than sufficient, and as far as I can tell, no widely circulated version of the story does.

What the guidance actually says

It is worth going to the specifications rather than the blog posts, because they are less absolute than the convention that grew out of them.

Material Design's metrics and keylines page states that "All components align to an 8dp square baseline grid for mobile, tablet, and desktop." That is the sentence everyone quotes. The two sentences after it are the ones nobody does: "Iconography in toolbars align to a 4dp square baseline grid," and "Type aligns to a 4dp baseline grid."

So Google's own system is a four point system with an eight point preference for the outer boxes of components. The finer material, the icons and the text, was always on four. Reading Material as an eight point grid is reading half of it.

The same page sets the touch target rule, and here the reasoning is physical rather than arithmetical: "To ensure balanced information density and usability, touch targets should be at least 48 x 48 dp", and "Size elements at least 48dp high and wide to ensure a physical size of about 9mm regardless of screen size. The recommended target size for touchscreen objects is 7-10mm." That is a fingertip measurement, not a pixel one. It happens to be divisible by eight. It did not have to be.

On the Apple side I have to record a gap. Apple's current Human Interface Guidelines are delivered as a JavaScript application, and I was not able to retrieve the text of the layout pages in this session. I can verify Apple's points-and-pixels model from the archived developer documentation quoted above. I cannot verify, and so will not assert, that Apple publishes a spacing grid unit comparable to Material's 8dp. My working belief is that it does not, and that the eight point grid on iOS is a convention designers imported rather than one Apple specified, but I have not confirmed it and you should treat it as unconfirmed.

The web never had this constraint in the first place

CSS defines its pixel absolutely: "1px = 1/96th of 1in", anchored to a reference pixel that the specification describes as "the visual angle of one pixel on a device with a device pixel density of 96dpi and a distance from the reader of an arm's length". But it then hands the whole thing back to the device:

For screen media (including high-resolution devices), low-resolution devices, and devices with unusual viewing distances, it is recommended instead that the anchor unit be the pixel unit. For such devices it is recommended that the pixel unit refer to the whole number of device pixels that best approximates the reference pixel.

"Whole number of device pixels that best approximates" is doing a lot of work, and on desktop it is routinely ignored. Microsoft's own DPI documentation describes a mode in which "All display scale factors in this mode are constrained to be one of these four values: 100%, 125%, 150%, 200%", mapping to 96, 120, 144 and 192 DPI, and notes that the older single-scale-factor mode allows custom values "limited to the range (100%-500%)".

Take 125%. A 1px border becomes 1.25 device pixels. A 4px radius becomes 5, which is fine, and a 2px rule becomes 2.5, which is not. No grid unit at the layout level rescues a hairline at a fractional scale factor, because the problem is not the spacing, it is the stroke. This is the single most common way the eight point grid gets blamed for something it was never able to fix.

Where four is better, concretely

Three cases, in the order I run into them.

Anything measured in fingertips

WCAG 2.2's Success Criterion 2.5.8 Target Size (Minimum) requires that "The size of the target for pointer inputs is at least 24 by 24 CSS pixels", with exceptions. The enhanced criterion, 2.5.5, requires "at least 44 by 44 CSS pixels". Twenty-four sits on both grids. Forty-four sits on the four point grid and does not sit on the eight point grid at all. If you have committed to eight, the accessible target is 40, which fails, or 48, which is Material's number and is often larger than the design wants. Four gives you 44 and the argument ends.

Type

Leading is where an eight point commitment does the most damage. Set 14px text and the plausible line heights are 20 and 22, neither of which is a multiple of eight. Forced to 24, the paragraph opens up past where it wanted to be; forced to 16, it closes. Material already conceded this: type aligns to four. A text-heavy interface is a four point interface whether or not its documentation admits it.

Dense interfaces

In a table row, a toolbar or an inspector panel, the difference between 4 and 8 points of internal padding is the difference between a compact control and a loose one, and there is nothing in between on an eight point scale. The usual workaround is to declare 4 a "half step", which is a four point grid with extra paperwork.

What I do now

I set the base unit at 4 and build the scale from it, not from 8. The spacing tokens are 4, 8, 12, 16, 24, 32, 48, 64. That is a four point grid with an eight point habit: the values I reach for most are still multiples of eight, because coarse rhythm is genuinely easier to read and easier to hold in a team's head, but 4, 12 and 44 are available without an argument about whether they are allowed.

The rule I would defend is this. The device pixel argument is real, it is about the 0.75x and 1.5x factors, and it terminates at four. Everything beyond four is a decision about how many choices you want your team to have, which is a legitimate decision and a completely different kind of claim. Keep the two apart. When someone says a value is wrong because it breaks the grid, ask which of those two arguments they are making. If it is the pixel one, check the arithmetic, because on a 2.608x panel that renders at 3x and downsamples, nobody's grid was ever landing on a whole pixel.

Sources

• Android Developers, "Support different pixel densities", Google. Density qualifiers, dpi values, scale factors, the 3:4:6:8:12:16 ratio, the definition of dp and the formula px = dp * (dpi / 160). https://developer.android.com/training/multiscreen/screendensities

• Material Design, "Metrics & keylines", Layout. The 8dp square baseline grid, 4dp grids for iconography and type, 48 x 48 dp touch targets and the 7-10mm physical rationale. https://m1.material.io/layout/metrics-keylines.html

• Apple Inc., "Drawing and Printing Guide for iOS: iOS Drawing Concepts", Apple Developer Archive. Points versus pixels, logical coordinate space, scale factors of 1.0 and 2.0. https://developer.apple.com/library/archive/documentation/2DDrawing/Conceptual/DrawingPrintingiOS/GraphicsDrawingOverview/GraphicsDrawingOverview.html

• Apple Inc., "iOS Device Compatibility Reference: Displays", Table 2-1 Screen Geometry, Apple Developer Archive. Native resolution, UIKit size, native and UIKit scale factors, and the statement that iOS renders at the UIKit scale factor and then downsamples. https://developer.apple.com/library/archive/documentation/DeviceInformation/Reference/iOSDeviceCompatibility/Displays/Displays.html

• Elliot Dahl, "Intro to the 8-Point Grid System", Built to Adapt, 14 December 2016 (updated 13 June 2017). The half-pixel argument for 8 and the credit to Bryn Jackson's earlier post. https://medium.com/built-to-adapt/intro-to-the-8-point-grid-system-d2573cde8632

• W3C, "CSS Values and Units Module Level 3", Absolute lengths. 1px = 1/96th of 1in, the reference pixel definition, and the recommendation that the anchor unit be the device pixel on screen media. https://www.w3.org/TR/css-values-3/

• Microsoft, "DPI-related APIs and registry settings", Windows Hardware documentation. Scale factors of 100%, 125%, 150% and 200% mapping to 96, 120, 144 and 192 DPI, and the 100-500% custom range. https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/dpi-related-apis-and-registry-settings

• W3C Web Accessibility Initiative, "Understanding Success Criterion 2.5.8: Target Size (Minimum)", WCAG 2.2. The 24 by 24 CSS pixel minimum. https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html

• W3C Web Accessibility Initiative, "Understanding Success Criterion 2.5.5: Target Size (Enhanced)", WCAG 2.2. The 44 by 44 CSS pixel figure. https://www.w3.org/WAI/WCAG22/Understanding/target-size-enhanced.html

Related reading

• Colour Spaces, and Why Your Gradient Goes Grey

• A Type Scale Is a Convention, Not a Law

• Designing the Empty State

• Two Laws Designers Quote and Misuse

More from the Moc Mallen Studio journal