The Breakpoint Tester renders your HTML across several viewport widths at once, so you can see how a layout reflows from a 320px phone to a 1440px desktop without dragging a browser window back and forth. Paste markup into the editor and it appears live inside each selected device frame side by side, with the exact pixel width labeled above every preview.
Under the hood, responsive layout is driven by CSS min-width media queries and modern intrinsic sizing. The default snippet uses grid-template-columns: repeat(auto-fit, minmax(120px, 1fr)), which reflows column count purely from available width. Seeing that behavior at 375px versus 768px versus 1440px simultaneously is far more revealing than testing one size at a time, because reflow bugs usually hide in the transition between two breakpoints.
The built-in Tailwind reference maps each utility prefix to its underlying media query: sm is min-width 640px, md 768px, lg 1024px, xl 1280px, and 2xl 1536px. That reference matters because Tailwind's breakpoints do not line up one-to-one with common device widths, and mixing the two mental models is a frequent source of layout surprises.
Using the tester
- 1
Pick your viewports in the Viewports row. Toggle any combination of Mobile S (320px), Mobile M (375px), Tablet (768px), Laptop (1024px), Desktop (1440px), and more; each active width renders as its own preview frame.
- 2
Replace the sample markup in the HTML to test box with your own component or page fragment. The previews update as you type, so you can watch a layout reflow in real time.
- 3
Compare the frames side by side. Each frame shows its true target width even though frames wider than 400px are scaled down to fit, so the internal layout still reflects the real breakpoint.
- 4
Flip on Show Tailwind Reference to see the sm through 2xl scale bar and table, then click any @media (min-width: …) row to copy the exact query to your clipboard.
When you'd reach for this
Catching the awkward in-between width
Layouts often break not at 375px or 1440px but at the tablet range around 768px where a two-column grid is neither comfortably one nor cleanly three columns. Rendering that width next to its neighbors exposes the problem instantly.
Verifying auto-fit and auto-fill grids
CSS Grid track functions like repeat(auto-fit, minmax(...)) change column count implicitly with width. This tester shows the actual column count at each viewport so you can tune the minmax floor without guessing.
Reconciling design widths with Tailwind prefixes
When a design calls for a change at 768px but your md: prefix also fires at 768px while your device is 375px, the reference table removes the ambiguity between device pixels and Tailwind's min-width thresholds.
Reviewing a snippet without a full build
For a bug report or a quick component sanity check, paste the raw HTML and inline styles here instead of spinning up the whole app just to see how one card reflows.
Practical notes and gotchas
- Design mobile-first. Tailwind's prefixes are min-width, meaning an unprefixed utility applies everywhere and md: only adds styles at 768px and up. Writing max-width-first fights the framework and produces override chains that are hard to reason about.
- Tailwind breakpoints are not device widths. sm at 640px sits between common phone (375px) and tablet (768px) sizes, so a component that looks fine on a real device can still cross a Tailwind threshold you did not intend. Check both the device frame and the reference scale.
- Test the extremes, not just the middle. 320px (Mobile S) is still a realistic floor for older and small Android phones; if text wraps badly or a fixed-width element overflows there, users will see a horizontal scrollbar.
- Prefer intrinsic techniques over hard breakpoints where you can. clamp() for fluid type, minmax() for grid tracks, and flex-wrap often eliminate whole breakpoints, giving you fewer discrete jumps to test and smoother behavior between them.
- Remember this previews CSS width only. It does not emulate touch input, device pixel ratio, safe-area insets, or a real mobile browser's UI chrome, so validate final builds on actual hardware before shipping.
Common questions
What are the default Tailwind CSS breakpoints?+
Tailwind's default breakpoints are sm (min-width 640px), md (768px), lg (1024px), xl (1280px), and 2xl (1536px). They are all min-width based, so each prefix applies from that width upward.
What is the difference between a device width and a CSS breakpoint?+
A device width is the physical viewport size of a screen, such as 375px on many phones. A CSS breakpoint is a threshold in a media query where your styles change. They frequently do not match, which is why a responsive design tester shows both.
What screen sizes should I test for responsive design?+
At minimum test a small phone (around 320-375px), a tablet (768px), and a desktop (1280-1440px). Also check the widths just around your own breakpoints, since reflow bugs tend to appear in the transition, not at the extremes.
Why does my layout break at 768px specifically?+
768px is both a common tablet width and Tailwind's md breakpoint, so a layout can change there for two reasons at once. If a two-column grid looks cramped, the fix is usually adjusting the grid track floor or moving the breakpoint, not adding more columns.
Is min-width or max-width better for media queries?+
min-width (mobile-first) is generally preferred and is what Tailwind uses. You define the base mobile layout with no query and progressively enhance for larger screens, which keeps specificity and override order predictable.
Can I test responsive layouts without a full build?+
Yes. A screen size tester like this renders raw HTML with inline or embedded CSS directly in the browser, so you can preview how a component reflows across viewports without compiling or deploying your project.