Define custom Tailwind breakpoints as name:pixel pairs — visualized to scale, exported as v4 –breakpoint-* variables, a v3 screens config, or raw media queries.
Settings
Generated locally in your browser — your settings and results never leave this page.
Breakpoints where YOUR layout breaks
Device-name breakpoints age badly; the durable ones come from your content — resize until the design fails, mark the width. Enter them as name:pixel pairs and get the to-scale visualization plus all three output dialects: v4 –breakpoint-* variables, a v3 screens config (with the extend-vs-replace decision handled), and raw media queries for documentation.
Worked example (v4)
@theme {
--breakpoint-compact: 600px;
--breakpoint-medium: 900px;
--breakpoint-expanded: 1240px;
}
<div class="hidden expanded:block">…</div>The replace-vs-extend footgun
- In v3, defining screens REPLACES the defaults — sm:/md:/lg: vanish unless re-declared, breaking every existing responsive class. The extend option adds instead; the tool defaults safely and explains both.
Mobile-first, restated
- Each variant applies from its min-width UP — unprefixed utilities are the mobile styles. Designing desktop-down? Tailwind also generates max-* variants for every breakpoint you define.
Limitations
- Range and container-query variants are per-use decisions in markup, outside a config generator’s scope.
Mobile first means unprefixed
In Tailwind an unprefixed utility applies at every width, and a prefixed one applies from that breakpoint upwards. So text-sm md:text-base is small by default and larger from the medium breakpoint on — there is no max-width rule involved.
Worked example
sm 640px md 768px lg 1024px xl 1280px 2xl 1536px class="w-full md:w-1/2 lg:w-1/3" full width, half from 768px, a third from 1024px
Why min-width only
Because mixing min and max width rules produces overlapping conditions that fight each other. A single direction means each breakpoint simply overrides the one below it, which is why a mobile-first cascade stays predictable as it grows.
Choosing your own
The defaults are sensible and arbitrary. Breakpoints should follow where your content actually breaks, which you find by widening the browser until the layout looks wrong — not by listing device sizes, of which there are now too many to enumerate.
Limits
Generates classes and configuration; Tailwind still compiles them. Everything runs in your browser.
How to use the Tailwind Breakpoint Generator
- List breakpoints as name:pixels, one per line or comma-separated.
- Check the to-scale bars for sanity.
- Export as v4 –breakpoint-* variables, v3 screens config, or raw media queries.
Frequently asked questions
What do custom breakpoints give me?
Named variants: defining content:900 creates content:flex, content:hidden and every other utility at that width — your layout's real inflection points instead of generic device sizes.
Replace or extend the defaults?
Replacing removes sm/md/lg/xl unless re-declared — a classic footgun. The extend option (v3) adds yours alongside the defaults; in v4, @theme values merge with defaults unless you reset the namespace.
Where should breakpoints come from?
From where YOUR layout breaks, not from device lists: resize until the design fails, set a breakpoint there. Tailwind's mobile-first min-width model means each one applies from its width upward.
