Cover image: Why I built Breakpoint Preview
Back to blog
Frontend · · 4 min read

Why I built Breakpoint Preview

A short story about tab switching while building responsive sites and a CLI that shows every viewport at once.

dxtoolingopen-source

At some point I was sitting there with two monitors, four browser windows, and a vague hope that the mobile variant would somehow line up. DevTools in responsive mode on the side, switch to 375 quick, back to desktop, then 768, then realize I was on the wrong tab. That’s not how you build responsive sites. That’s how you build tab switches.

The annoying part isn’t the time per switch. It’s the friction in your head. Every time I jump from desktop to mobile, I lose the thread of what I was actually trying to compare. That’s how breakpoint-preview came about.

What it does

A CLI that renders your running site at several viewport widths next to each other at the same time. Defaults are 375, 768, 1024, and 1440. Type a URL, all four react. Hot reload keeps working as usual, because the tool drops a small proxy in front of your dev server and passes the WebSocket connections through.

375px
Mobile
768px
Tablet
1024px
Laptop
1440px
Desktop
Four viewports at once, one URL, one browser tab.

Each viewport has its own URL bar, so you can point a single frame at a different route to check a specific mobile view while desktop stays on the overview. Scroll sync is optional, viewports can be hidden individually, and state persists across reloads.

How I use it

While building, I keep it open in a second window while DevTools stay on desktop in the main tab. As soon as I touch a card or a layout, I can see on save whether tablet breaks or mobile gets too tight, without actively looking.

For bug reports from designers or clients (“can you check this on mobile”) I skip the back and forth between sizes. I open the tool, scroll through once, see all four breakpoints in a single glance.

For AI agents there’s a SKILL.md in the repo so Claude Code or Codex can launch the tool themselves and navigate viewports when they’re working on responsive code. Works with any framework that has a dev server: Vite, Next, SvelteKit, Astro, Remix, plain HTML. Last step before pushing: npx breakpoint-preview http://localhost:5173, scroll once, done.

How it works

Under the hood it’s a local proxy that forwards all requests to your dev server. That makes all viewports same-origin, which is what enables scroll sync and per-viewport URLs in the first place. WebSocket connections for HMR are passed through transparently. No extension, no config file, no dependencies besides Node itself. With the --app flag it opens as a standalone window without browser chrome, which makes it feel like its own app.

What stuck with me

What stayed with me after building this isn’t the tool itself, it’s how much tab switching I had quietly accepted as a normal part of the job. Once the four frames sit next to each other, you notice how often you used to jump into mobile view without thinking about it. I now test responsive in passing instead of at the end, and that changes the final result more than any single mobile fix.

More to read

More articles around frontend, design and technology.

Back to blog
Privacy notice

This website only uses technically necessary cookies. No analytics or marketing cookies are used. Privacy policy