Responsive web design solved text and images years ago. Charts are still routinely broken on small screens, and the reason is structural: text reflows, but a chart's meaning depends on its geometry. Halve the width of a paragraph and it gets taller. Halve the width of a chart and you may destroy the comparison it existed to show.

Making charts responsive is therefore not a matter of setting a percentage width. It requires deciding, per breakpoint, what the chart is for and what can be sacrificed.

Several failures compound at once. Axis labels that fit comfortably at a thousand pixels overlap at four hundred, and libraries respond by rotating them to forty-five degrees, which is harder to read, or dropping every other one, which hides categories. Legends that sit to the right consume a third of an already narrow canvas. Tooltips triggered by hover never fire on a touch device. Data density that was reasonable becomes several points per pixel. And a fixed aspect ratio that looked balanced becomes either a letterbox strip or a column taller than the viewport.

Individually each is a nuisance. Together they produce a chart that is present but unreadable, which is worse than a chart that was deliberately replaced with a summary number.

The first structural fix is to stop responding to viewport width. A chart does not care how wide the browser is; it cares how wide its own container is. The same chart component may appear full-bleed on one page and in a narrow sidebar tile on another, at identical viewport sizes.

Observe the container's dimensions directly and re-render when they change. Debounce the handler, because resize events fire far more often than you need to redraw, and a heavy chart redrawing on every pixel of a window drag will drop frames. Also handle the case where the container starts at zero width, which happens when a chart is inside a collapsed panel or a tab that is not yet visible. Rendering into a zero-width box produces a chart that stays blank after the panel opens, and it is one of the most common bugs in dashboard code.

Instead of shrinking everything proportionally, decide what each screen size shows. Think of it as three tiers.

On a large screen, show everything: full axes, gridlines, a legend, data labels, and any secondary annotations. On a medium screen, drop the least load-bearing elements first, usually data labels and minor gridlines, and move the legend from the side to the top or bottom where it costs height rather than width. On a small screen, reduce to the essential comparison: fewer axis ticks, no legend in favour of direct labels or a caption, and often fewer series.

The important discipline is that this is an editorial decision, not an automatic one. Ask what single question the chart answers. Everything required to answer that question stays at every size; everything else is negotiable.

Long category labels are the most frequent cause of small-screen breakage, and the best fix is usually to change the chart's orientation. A horizontal bar chart gives labels the full width of the container and stacks categories vertically, which suits a tall narrow viewport far better than a vertical column chart with rotated labels.

For time axes, reduce tick density rather than rotating. Twelve month labels become four quarter labels; thirty day labels become weekly ticks with the month shown once. Abbreviate consistently, and keep the first and last tick, since those anchor the range.

Numeric axes benefit from shorter formats on small screens: thousands and millions abbreviated, decimal places dropped, currency symbols shown once in the axis title rather than on every tick. Each of these reclaims horizontal space that the plot area can use.

Hover does not exist on touch devices, so any information available only on hover is invisible to mobile users. If your tooltip contains the exact values, mobile users have no access to exact values.

Design a touch path explicitly. Make tap select a data point and show a persistent tooltip that stays until dismissed, rather than one that vanishes on the next touch. Size hit areas generously, at least around forty-four pixels, which usually means an invisible target larger than the visible mark. Where a chart has many small points, consider snapping to the nearest point along the axis rather than requiring a precise hit.

Be careful with gestures. Pinch to zoom inside a chart competes with the browser's page zoom, and a chart that captures vertical drag will trap the user who was trying to scroll past it. A safe default is to let the page own scrolling and provide explicit zoom controls, or require a deliberate two-finger gesture for panning within the plot.

Sometimes the right response to a narrow screen is a different visualization. A grouped bar chart with four series across twelve categories is unreadable at phone width no matter how it is scaled. A heatmap with fifty columns cannot be usefully compressed.

Reasonable substitutions include replacing a multi-series grouped chart with a single-series chart plus a category selector, replacing a wide heatmap with a sorted list of the top values, replacing a scatter plot with a summary of the correlation and a few labelled outliers, and replacing a small chart entirely with the single number it was illustrating plus a sparkline.

This feels like giving up, but it is the opposite. A number the user can read beats a chart they cannot.

Mobile devices have less memory, slower processors, and often a slower network. They also frequently have high pixel density, which means a canvas rendered at device resolution has several times the pixels of the same chart on a standard desktop display.

Cap your pixel ratio for rendering rather than always matching the device, since the visual gain above two is minimal and the memory cost is quadratic. Reduce animation on small screens or disable it entirely, because an animated transition that is smooth on a laptop can stutter on a mid-range phone and stuttering reads as broken. Downsample data before rendering, and defer charts that are below the fold until they scroll into view. If your charting library supports it, prefer canvas over vector rendering when point counts are high, since thousands of individual vector nodes are expensive for the browser to lay out.

Browser device emulation is useful for layout and useless for performance and touch. It will not show you that your tooltip is unreachable, that your tap targets are too small, or that a transition drops frames.

Test on at least one real low-end device, and test in the conditions people actually use: outdoors with glare, one-handed, on a slow connection. Check both orientations, since landscape on a phone gives you desktop-like width with almost no height. Verify the collapsed-container case by loading a page with a chart inside a closed accordion and then opening it. Confirm that a chart still makes sense at the smallest width you support rather than only at the standard device presets.

Responsive charts require you to admit that a small screen cannot carry as much information as a large one, and then to choose what survives. The failure mode is not choosing, and letting the library scale everything down until nothing is legible.

Decide what each chart is for. Keep that at every size. Let the rest go.