Skip to the tool
OnPageKit

Media Query Checker

List your CSS breakpoints and find overlaps and gaps.

a stylesheet, or a page with <style> blocks

Read in this tab; nothing is fetched or uploaded. 1em in a media query is always 16px, whatever the page font size.

@media rules
0
Breakpoints
0
min / max
0 / 0
Units
  • No @media rules found in this CSS.

Everything runs in your browser. Nothing you type is sent to a server.

Found a bug in this tool? Report it.

Share this tool

What this tool does

This media query checker reads the CSS you paste — or a whole HTML page, in which case it reads the <style> blocks — and lists every @media rule with its line number and the width range it actually covers. It then builds a sorted CSS breakpoints list: each distinct width, written in pixels, with the ways it appears in the source and how often.

On top of the inventory it checks the things that break responsive layouts quietly: min-width and max-width queries mixed in one stylesheet, px and em mixed, two ranges that both apply at the same pixel, gaps where a fractional width matches neither, conditions that can never be true, invalid units, deprecated device-width features and, for HTML, a missing or zoom-blocking viewport tag.

How to use it

  1. Paste a stylesheet, or the source of a page. Minified CSS is fine.
  2. Read the breakpoint list first. It is the fastest way to see whether your responsive breakpoints are a system or an accumulation.
  3. Work through the findings, which carry the line they came from. The full rule list at the bottom shows each query translated into a plain range, such as "from 768px up to 1023.98px".

Everything runs in this tab. Nothing is fetched, so linked stylesheets are not followed — paste the CSS file itself if the queries live there.

min-width vs max-width

A mobile-first stylesheet writes the small-screen layout as the default and adds to it with min-width queries as the screen grows. A desktop-first one does the opposite with max-width. Neither is wrong. Mobile-first usually produces less CSS, because narrow layouts are simpler and the wide ones build on them instead of undoing them.

What goes wrong is the edge between two ranges. max-width: 768px and min-width: 768px both match at exactly 768px, so both blocks apply and whichever comes later wins. max-width: 767px and min-width: 768px leave a sliver in between, and zoomed pages really do report widths like 767.5px. The checker reports both and suggests the fix: end the lower range at 767.98px, or use the range syntax (width < 768px) and (width >= 768px), which states the intent exactly.

Units, and the viewport tag

A media query ignores the page's font size: 48em is 768px at the browser default whatever your html rule says. That is the point of em breakpoints — they move when a visitor raises their default font size. Mixing em and px means some parts of the layout respond to that setting and others do not.

None of this matters on a phone without <meta name="viewport" content="width=device-width, initial-scale=1">. Without it the browser pretends to be a desktop and every small-screen query is dead. And do not add user-scalable=no while you are there: blocking zoom fails accessibility guidelines.

For the rest of the page, the meta tag analyzer checks the head you just pasted, the DOM size checker looks at markup weight, and the deprecated HTML tags checker finds layout markup that should have been CSS.

Frequently asked questions

Should I use min-width or max-width media queries?

Either works, and the choice matters less than being consistent. min-width is mobile-first: the base styles are for small screens and each query adds layout as space grows, which tends to produce less CSS to override. max-width is desktop-first. The real problem is mixing them, because every change then has to be reasoned about from both directions.

Why use 767.98px instead of 767px?

Browsers can report fractional viewport widths when the page is zoomed or on some high-density screens. With max-width 767px and min-width 768px, a width of 767.5px matches neither query and falls back to base styles. Ending the lower range at 767.98px closes that gap. Range syntax, as in width < 768px, avoids the problem altogether and works in every current browser.

Should breakpoints be in px or em?

em breakpoints scale with the visitor's default font size, so someone who sets a larger font gets the narrower layout sooner, which is usually what they need. px breakpoints ignore that setting. Both are valid. In a media query 1em is always the browser default, normally 16px, regardless of the font size set on the page.

What breakpoints should I use?

Set them where your content breaks, not where a particular device sits. Common starting points are around 640, 768, 1024 and 1280 pixels, which is what Tailwind and most design systems use, but four or five breakpoints is plenty for most sites. A list of a dozen values a few pixels apart is usually a sign of one-off fixes.

Why do my media queries not work on phones?

The usual cause is a missing viewport meta tag. Without it, mobile browsers lay the page out at roughly 980 pixels wide and shrink it to fit, so queries for small screens never match. Add a viewport meta tag with width=device-width and initial-scale=1. Paste the HTML here and the checker flags it.

Related tools

Updated