Canvas mode: website breakpoint-by-breakpoint reviews

If you have ever dragged three browser windows around your screen just to compare mobile, tablet, and desktop, you will like this. We built Canvas mode to make responsive reviews effortless.

It lets you open a page once and see multiple breakpoints side by side. You can scroll, compare, and leave clear feedback without juggling tabs or asking the team for new screenshots.

But Canvas is more than a convenience feature. Side-by-side breakpoint review changes how you catch responsive bugs — and how quickly you fix them.

Why responsive issues are so hard to catch

Responsive design is deceptively simple in theory: build once, adapt to every screen. In practice, layouts break in unexpected ways at unexpected widths.

The problem isn't that teams don't test responsive behavior. It's how they test it.

The typical workflow (and why it fails)

1. Open the staging site in Chrome
2. Resize the browser window back and forth
3. Maybe open DevTools and toggle the device toolbar
4. Squint at one viewport at a time
5. Try to remember what the mobile version looked like while staring at desktop
6. Open a second window for comparison
7. Realize you can't see both at the same time without overlapping
8. Give up and just test desktop thoroughly

This workflow misses layout drift — subtle differences between breakpoints that only become visible when you compare them side by side. A section that looks fine on mobile and fine on desktop might have a broken state at 768px that nobody checked.

Common responsive bugs that slip through

• Sticky headers that overlap content on tablet but work fine on mobile and desktop
• Button text wrapping at one viewport width while looking normal everywhere else
• Grid misalignment when a 3-column layout becomes 2 columns at 1024px
• Spacing inconsistencies where padding or margin values differ between breakpoints for no reason
• Font size jumps where type scales from 14px to 24px between two breakpoints with no intermediate step
• Overflow issues where horizontally scrolling content appears at specific widths
• Image aspect ratios that shift when container widths change

These aren't edge cases. They're the most common responsive bugs on every project. And they're almost impossible to catch without side-by-side comparison.

What Canvas mode does

In Huddlekit, Canvas is a dedicated view for responsive QA. You choose the breakpoints you care about and review them in parallel on the same screen.

Core capabilities

• Side-by-side viewport comparison. See mobile, tablet, laptop, and desktop simultaneously — all rendering the same live page.
• Real device presets. Choose from actual device widths: iPhone SE (375px), iPhone 14 Pro (393px), iPad (768px), MacBook (1024px), iMac (1440-1920px). Or set custom widths.
• Pin comments per viewport. Leave a comment on the mobile version without affecting the desktop thread. Each pin is tied to its specific breakpoint.
• Live page rendering. Canvas runs on the actual live page, so you see real behavior — hover states, sticky elements, animations, JavaScript interactions. Not a static screenshot.
• Adjustable zoom. Zoom in on a specific breakpoint to examine details, or zoom out to see the full layout at a glance.

Canvas vs. single-device review

The breakpoints that matter

Not every pixel width needs review. Focus your Canvas on the breakpoints that actually matter for your project.

Standard breakpoints

These cover the vast majority of real-world devices:

• 375px — iPhone SE and small Android phones. The tightest constraint — if your layout works here, it works on all phones.
• 428px — iPhone Pro Max and large Android devices. Tests the upper range of mobile.
• 768px — iPad portrait and small tablets. The most common breakpoint where layouts shift from mobile stacking to multi-column.
• 1024px — iPad landscape and small laptops. Often where a 2-column layout becomes 3-column.
• 1280px — Standard laptops and small desktops. The "default" desktop experience for most users.
• 1440px — Large desktops and external monitors. Tests whether your max-width containers hold up.
• 1920px — Full HD monitors. Catches issues with ultra-wide layouts.

Which breakpoints to actually test

For most projects, four breakpoints are sufficient:

1. 375px (mobile baseline)
2. 768px (tablet / first layout shift)
3. 1024px (laptop / second layout shift)
4. 1280px (desktop baseline)

Add 1440px or 1920px only if your audience skews toward large-screen users (B2B dashboards, data-heavy applications).

Custom breakpoints

If your CSS uses non-standard breakpoints, set Canvas to match. There's no point testing at 768px if your layout shifts at 800px. Check your project's Tailwind config or CSS media queries to identify the actual breakpoint values.

How teams use Canvas in practice

Here is a workflow we recommend for every responsive review.

Step 1: Set up your Canvas

Open your review link in Huddlekit and switch to Canvas mode. Add four viewports: mobile (375px), tablet (768px), laptop (1024px), desktop (1280px). Arrange them left to right, smallest to largest.

Step 2: Review key templates top-down

Start with the components that appear on every page:

1. Navigation bar — Does it collapse to a hamburger on mobile? Does the hamburger actually open? Are all links visible on desktop?
2. Hero section — Does the headline break naturally on mobile? Is the CTA button reachable without scrolling?
3. Content grids — Do cards stack properly on mobile, show 2 columns on tablet, 3 on desktop?
4. Forms — Are inputs full-width on mobile? Do labels align correctly at every width?
5. Footer — Does the column layout make sense on mobile? Are social links tappable (minimum 44px touch target)?

Step 3: Scroll through each page together

Canvas keeps all viewports in sync when you scroll, so you can see how each section adapts as you move down the page. Watch for:

• Sections that look great on desktop but feel cramped on mobile
• White space that appears on tablet but not elsewhere
• Elements that overlap or get clipped at specific widths

Step 4: Pin issues where you see them

One pin per problem keeps things clear. Be specific in your comment:

Good: "At 768px, the pricing cards stack to 1 column but the section has enough width for 2. The md:grid-cols-2 class might need to kick in at 768px instead of 1024px."

Not helpful: "Cards look weird on tablet."

Your developer gets a notification with the issue, the exact viewport, and the visual context. No back-and-forth needed.

Step 5: Re-check after fixes

After the developer resolves issues, open the same Canvas preset and verify. The consistent viewport setup means you're comparing apples to apples — not "I think mobile looked fine last time."

Common responsive issues and what to look for

Typography

• Font size jumps. Headlines that go from 16px on mobile to 48px on desktop in one step, with no intermediate size at tablet. This creates a jarring experience.
• Line length. On desktop, paragraphs wider than 75 characters become hard to read. On mobile, lines shorter than 35 characters feel choppy.
• Letter spacing. Tracking that works at 14px can feel too tight or too loose at 32px. Check headings at every breakpoint.

Spacing

• Inconsistent padding. Section padding of 16px on mobile, 64px on desktop, and 24px on tablet feels random. Spacing should scale proportionally.
• Margin collapse. Adjacent margins that collapse differently depending on whether elements stack vertically (mobile) or sit side by side (desktop).
• Container widths. Content that stretches to full width on mobile should have sensible max-widths on desktop. Unbounded text at 1920px is unreadable.

Layout

• Grid orphans. A 3-column grid with 5 items leaves one item alone on the second row. At tablet (2 columns), it's 2-2-1. Check that orphaned items don't look broken.
• Sticky element conflicts. A sticky sidebar that works on desktop might overlap the header on tablet, or take up too much screen real estate on mobile.
• Overflow. Horizontally scrolling tables, code blocks, or wide images that bleed outside their container on narrow viewports.

Interactive elements

• Touch targets. Buttons and links need a minimum 44x44px tap area on mobile. Canvas makes it easy to spot targets that are too small.
• Hover states. Hover-dependent interactions (dropdown menus, tooltips) need touch-friendly alternatives on mobile.
• Focus states. Tab order should make sense at every viewport. A sidebar that appears first in the DOM but displays on the right side of desktop can create a confusing tab order on mobile where it stacks on top.

Pairing Canvas with Inspect mode

Canvas tells you what looks wrong. Inspect mode tells you why.

When you spot an issue in Canvas — say, a headline that's too small on tablet — switch to Inspect mode and hover over the element. You'll see the computed CSS: font-size, font-weight, line-height, padding, margin, and colors. No need to open DevTools or switch tabs.

This is especially useful for:

• Verifying that a design's specified font-size: 18px actually rendered as 18px
• Checking whether padding differences between breakpoints are intentional or accidental
• Confirming color values match the brand palette at every viewport

Read more about CSS inspection for faster QA.

Tips for clean responsive reviews

• Start with mobile. It's the tightest constraint. If mobile works, the other breakpoints are usually closer to correct.
• Use consistent zoom. Zooming in on one viewport and not others skews your comparison.
• Review components in isolation, then in context. A button might look fine alone but break when placed next to a long headline.
• Check dark mode if applicable. Responsive issues and theme issues often compound — a text color that's readable on desktop light mode might fail contrast on mobile dark mode.
• Recheck after every fix. CSS changes at one breakpoint can cascade to others. What you fixed on mobile might now break on tablet.
• Document your breakpoint presets. Save your Canvas configuration so every review round uses the same viewports. Consistency makes comparison meaningful.

Beyond visual review

Canvas is primarily a visual tool, but it also surfaces issues that aren't immediately obvious:

• Performance differences. Pages that load fine on desktop over fast Wi-Fi might feel sluggish on a simulated mobile viewport. Watch for heavy images or scripts that aren't optimized for smaller screens.
• Content prioritization. Mobile forces you to stack content linearly. This makes it obvious when the most important content is buried below less important elements.
• Accessibility. Smaller viewports compress interactive elements together. Canvas makes it easy to check whether buttons and links are still comfortably tappable.

Final thought

Canvas makes responsive reviews calm and obvious. Side by side, breakpoint by breakpoint. No tab juggling. No guesswork. No "I think it looked different last time."

The result is faster reviews, fewer missed bugs, and websites that genuinely work on every device — not just the one the designer happened to have open.

Ready to try it on your next launch?

Try Canvas in Huddlekit

Related resources

• How to inspect CSS for faster website QA — pair Canvas with Inspect mode
• A website review process that actually works — the full review workflow
• Breakpoint comparison — what it means and why it matters
• Responsive testing — testing across devices and viewports
• Best website annotation tools — tools compared