Breakpoint Calculator

CSS breakpoints are specific viewport widths at which a website's layout changes to provide the best possible user experience for that screen size. They are the foundation of responsive web design — the technique that makes a single codebase render correctly on everything from a 320px mobile phone to a 2560px ultrawide monitor.

When a browser window reaches a breakpoint width, CSS rules inside the corresponding media query activate, allowing developers to reflow content, resize elements, show or hide UI components, and adjust typography. Without breakpoints, a layout designed for a large desktop would render at full scale on a phone, forcing users to zoom and scroll horizontally just to read a headline.

Modern CSS frameworks like Tailwind CSS, Bootstrap, Foundation, and Material UI each ship with a predefined set of breakpoints tuned to the most common device categories: phones, tablets, laptops, and large desktop monitors. Understanding where these thresholds sit — and how they differ between frameworks — is essential for developers who work across multiple projects or who migrate code between systems.

This breakpoint calculator lets you select a framework, enter any test width in pixels, and instantly see which breakpoint tier is active, the corresponding CSS media query code, and the CSS custom property declarations you can paste directly into your stylesheet. Quick-test buttons for Mobile (375px), Tablet (768px), Laptop (1024px), and Desktop (1920px) let you verify common device widths in seconds.

The calculator uses a mobile-first, min-width strategy — the same approach used by Tailwind CSS, Bootstrap 5, Foundation, and Material UI. Each breakpoint defines the minimum viewport width at which its styles apply. The currently active breakpoint is the highest-valued breakpoint whose minimum width does not exceed the test width you provide.

Internally the algorithm sorts all breakpoints in descending order by their pixel value, then scans through the sorted list until it finds the first breakpoint whose value is less than or equal to the test width. That is the active tier. All styles defined at that tier — and every lower tier — are simultaneously in effect at the given width.

For example, Tailwind CSS defines sm at 640px, md at 768px, lg at 1024px, xl at 1280px, and 2xl at 1536px. If your test width is 900px, the sorted list is checked in order: 1536 > 900, 1280 > 900, 1024 > 900, and then 768 ≤ 900 — so md is the active breakpoint. Styles applied at the md tier and all tiers below it (sm and unprefixed base styles) are active at 900px.

If no named breakpoint has a value at or below the test width — which happens in Tailwind when the viewport is under 640px — the result is none. This is correct behavior: Tailwind's unprefixed base styles apply at all widths, so "none" simply means no named prefix is currently engaged.

Different CSS frameworks choose different breakpoint values based on their design philosophy and the device landscape at the time of their creation. The table below compares the four frameworks supported by this calculator side by side, using their pixel values.

Bootstrap 5 and Material UI both define an explicit xs tier at 0px, meaning every width below the next named tier falls into a named bucket. Tailwind takes the opposite approach: styles written without a prefix apply at all screen sizes, while named prefixes only add rules at and above their threshold. Foundation uses descriptive names (small, medium, large) instead of abbreviations, which can improve readability in larger teams.

Note that Tailwind and Foundation share a 640px small breakpoint, while Bootstrap's sm sits 64px lower at 576px. This matters most when targeting landscape phones: a 600px-wide viewport is "sm" in Bootstrap and Material UI but falls below the first named breakpoint in Tailwind.

After you select a framework and enter a test width, the calculator outputs two ready-to-use code snippets: a set of CSS media queries and a block of CSS custom properties. Both can be copied to the clipboard in one click.

The media query output follows the standard min-width format used by every major framework. For each breakpoint with a non-zero minimum width, the calculator generates a rule in the form @media (min-width: Npx) { /* name */ }. Zero-based breakpoints are intentionally excluded from the media-query list because @media (min-width: 0px) is always true and adds no useful conditional logic — the styles you want applied universally belong in your base (unprefixed) CSS instead.

The CSS variables block wraps every breakpoint — including zero-based ones — into --breakpoint-[name] custom properties inside a :root selector. These are particularly valuable for JavaScript that needs to read breakpoint thresholds at runtime. You can retrieve a value with getComputedStyle(document.documentElement).getPropertyValue('--breakpoint-lg') and use the result to conditionally render components, trigger animations, or adjust Canvas dimensions — all without duplicating magic numbers in your JavaScript files.

Keeping breakpoint values in CSS custom properties ensures that your JavaScript thresholds stay synchronized with your stylesheet automatically. If you later adjust the lg threshold from 1024px to 1000px, updating the CSS variable is all that's needed — the JavaScript picks it up without a separate code change.

Breakpoints are one of the most misunderstood tools in CSS. A common mistake is designing for specific devices — choosing breakpoints that match the pixel dimensions of popular phone models. Device dimensions change rapidly and screen resolutions vary even within a single product line, so content-first breakpoints produce more durable, future-proof designs.

The preferred workflow is to start with the smallest possible layout (mobile-first), then progressively widen a browser window or the preview pane in your design tool. Add a breakpoint only when the content genuinely starts to look awkward — text lines becoming too long, images becoming too narrow, a grid that could accommodate another column. Each breakpoint should be motivated by the content, not by a device spec sheet.

When using a framework like Tailwind or Bootstrap, try to stay within the predefined tier system wherever possible. Custom breakpoints add complexity and make it harder for new developers joining a project to predict behavior. Reserve custom breakpoints for genuinely exceptional cases, such as a hero banner that needs a mid-tier adjustment not covered by the default scale.

Typography is often the first thing to suffer at untested widths. A comfortable reading line length is 45 to 75 characters per line. If your body text runs 120 characters wide on a large desktop, a breakpoint to cap the content width or switch to a multi-column layout is warranted. Similarly, very short lines on mobile feel cramped — always test at 320px, the smallest viewport still in widespread use among older Android devices.

Always test your breakpoints with real content, not placeholder text. Headings that fit neatly with a short title may overflow catastrophically with a longer one. Tables, code blocks, and data visualizations are notorious for breaking responsive layouts because they have intrinsic minimum widths that resist shrinking. Test every breakpoint boundary — both one pixel below and one pixel at the threshold — to catch the edge cases that cause sudden layout jumps.

The custom mode in this calculator lets you define your own breakpoint names and pixel values from scratch. This is valuable when you are working outside a standard framework — for instance, building a design system from scratch, adapting a legacy codebase, or tailoring a layout for a specific device fleet such as digital signage or point-of-sale kiosks where viewport widths are fixed and known in advance.

When defining custom breakpoints, start by auditing your analytics data for the most common screen widths among your actual users. Tools like Google Analytics and Plausible report screen resolution distributions for your specific audience, which may differ significantly from global averages. A B2B SaaS product used primarily on corporate desktops has a very different viewport-width distribution than a consumer recipe app visited mostly on phones.

Keep custom breakpoint sets small — three to five tiers is usually sufficient. Each additional breakpoint multiplies the number of layout states you need to test and maintain. Name breakpoints semantically (for example, "compact", "standard", "wide") rather than after devices (for example, "ipad") so names remain meaningful as technology evolves. The custom mode initializes with Tailwind's default breakpoints as a sensible starting point that you can then trim or extend.