Browser sizes we target (in pixels)

Owned by Adam Butterworth (Deactivated)
Last updated: Apr 07, 2021
2 min read

The data driving these decisions lives in an edx internal spreadsheet here: https://docs.google.com/spreadsheets/d/1lhcnDo1Zsd7eWCP3_hz5oAHyYRB9ShCKgrEV0W6FLdU/edit#gid=908214725.

Goals behind the choices below:

  1. Keep the number of target sizes as small as possible.

  2. Target sizes that align with the largest segments of traffic.

  3. Create target sizes that make it more likely for us to create designs that work at 320 pixels wide (an a11y requirement).

  4. Avoid creating unnecessary work by splitting target screen sizes into tiers of attention.

The dimensions below:

  • are listed in pixels

  • represent a customer’s viewport not including browser chrome or scrollbars

  • have heights reflecting the most common location of the fold

Tier 1: Our primary sizes in design

  • 360 x 560

  • 1350 x 650

Other primary concerns

QA design or implementation at 320 pixels wide in scenarios likely to have issues.

If you are creating control bars or navigation bars that place buttons or fields on the left and right side of the viewport you should check your design at 320 pixels wide. You can preview an iPhone SE 1 in Chrome Dev Tools: Open Dev Tools, Turn on the Responsive viewport tool

Avoid having more than one sticky or fixed element on viewports less than 360 pixels wide.

This rule aims to ensure that the scrollable area of a page is at least 256px high.

Tier 2: Design for these sizes if it seems necessary

  • 320 x 450 This is the minimum width we must support to ensure our product is accessible.

  • 414 x 720

  • 1020 x 650

  • 1520 x 720

Tier 3: Check these sizes in QA

  • 375 x 550

  • 768 x 900

  • 1260 x 580

  • 1440 x 790

  • 1900 x 940