Site Breakpoints

Preview a page at the exact widths its own CSS cares about, instead of guessing at generic device sizes.

What Site Breakpoints Are

A breakpoint is a width threshold a site defines in its own stylesheets, the point where its layout is meant to change. In CSS, these live inside @media rules that test the viewport width, such as a rule guarded by min-width or max-width. A site's breakpoints are the specific widths where its design was built to reflow: a sidebar collapses, a navigation bar becomes a menu button, a grid drops from three columns to one.

Those widths are particular to each site. Two pages can look identical on a laptop and behave completely differently as they narrow, because their authors chose different thresholds. Site Breakpoints reads the thresholds a page actually declares, so you test that page against its own design intentions rather than against a fixed list of phones and tablets.

Detecting Them

Responsive Tester detects a page's breakpoints automatically when it activates, and re-checks them as you navigate. There is nothing to configure and nothing to run by hand. This is free.

Detection works by walking the page's own stylesheets and reading the width conditions out of every @media rule it finds. For each rule it extracts the min-width and max-width values, converts any em or rem values to their pixel equivalents (em against a fixed 16px, rem against the page's root font size), removes duplicates, and sorts the results from narrowest to widest. The output is a clean, ordered set of the distinct widths the page treats as significant.

A few details are worth knowing:

• Only the page's own CSS counts. Detection reads the stylesheets loaded by the page you are previewing, so the breakpoints reflect what that site declares, not any defaults.
• Cross-origin stylesheets are skipped. When a browser blocks script access to a stylesheet served from another origin, that sheet is passed over rather than causing an error. Breakpoints defined only in an inaccessible third-party sheet may not appear.
• Values are normalized to pixels. A threshold written as 40em or 48rem is resolved to its pixel equivalent so it lines up with the pixel widths of your viewports.
• Duplicates collapse. The same width referenced by several rules shows up once, so a large stylesheet with many media queries still yields a short, meaningful list.

Building Matching Viewports

Once a page's breakpoints are detected, you can build a set of viewports that match those widths in one click. Each detected width becomes a frame, so the page renders side by side at every threshold where its layout is designed to change. This is free.

The generated frames get sensible heights. Each one uses a reasonable default height, and when one of your existing viewports is already close in width to a detected breakpoint, the closest matching viewport lends its height instead. A 393px breakpoint sitting next to an iPhone-sized viewport picks up that device's taller height rather than the default, so the generated frames feel proportioned rather than uniform.

When It's Available

The Site Breakpoints control is only available when the page actually defines breakpoints in its CSS. If a page declares no width-based media queries, or its only breakpoints live in stylesheets that cannot be read, there is nothing to detect and the control stays inactive. There is no error and nothing to dismiss: on a page with no breakpoints, the feature simply has nothing to offer.

Because detection re-runs as you move between pages, the control follows the page you are looking at. It becomes available on pages that declare breakpoints and steps aside on pages that do not.

Why It Helps

Testing at generic device sizes tells you how a page looks on a particular phone or tablet. It does not tell you where that page's own layout switches, and the interesting bugs tend to live right at those switches: a hair below a threshold where three columns still try to fit, or a hair above one where a menu has not yet collapsed.

Site Breakpoints puts a frame at each of those exact widths, so you review the page at the moments its design was built to change instead of guessing which device sizes might land near them. You spend your attention on the transitions that matter to that specific site, and you catch layout problems at the widths where they actually occur.