How to hand off responsive typography to developers

How to hand off responsive typography to developers

A designer finishes a beautiful type ramp in Figma, exports a PDF spec, and emails it to engineering with the subject line “Final type styles.” Two weeks later, a production page renders at 17px on a 27-inch monitor, the H1 is wider than the container on mobile, and the team is in Slack trying to figure out who owns the fix. That gap between the artboard and the live page is almost always a typography handoff problem, not a design or engineering problem.

Responsive typography fails when the handoff treats type as a static set of pixel sizes instead of a system that has to behave across viewports, zoom levels, and density settings. The goal of a clean handoff is not to deliver more documentation. The goal is to give developers a self-describing type system they can implement once, scale across breakpoints, and tune without re-opening Figma. This guide walks through the practical mechanics of that handoff, from modular scales to fluid sizing, accessibility checks, and QA.

What “responsive typography” actually covers

Responsive typography is not only “text that shrinks on phones.” It is a set of behaviors that need to be specified and tested:

• Type size that scales smoothly between breakpoints rather than stepping abruptly.
• Line length that stays inside a readable measure on every viewport.
• Vertical rhythm that holds when the type size changes.
• Hierarchy that reads correctly at zoom levels between 80% and 200%.
• Color contrast that survives background swaps and dark mode.
• Font loading behavior that avoids layout shift and invisible text.

Each of these has design decisions and code consequences. A handoff that only lists “H1 = 48px” leaves developers guessing about the rest.

Start with intent, not sizes

Before opening a Figma library, write a short brief that answers four questions:

1. What is the smallest viewport the design must support, and what is the largest?
2. Where does long-form reading happen, and what measure is comfortable there?
3. Which type roles are decorative versus functional (body, UI, headings, code)?
4. What is the brand voice: editorial, technical, friendly, dense?

These answers drive the scale, the ratio, and the breakpoints. Skipping them is the most common reason a type system “looks right” in Figma and “looks off” in production.

Build a modular type scale you can defend

A modular type scale is a sequence of sizes generated from a base value and a ratio. It gives every role a place in a hierarchy and a reason for its size. Two scales most teams reach for:

Scale name	Base	Ratio	Typical feel	Watch out for
Minor third	16px	1.200	Subtle, dense, software-like	Headings can feel under-emphasized at small sizes
Major third	16px	1.250	Balanced editorial	Safe default; can feel flat for marketing pages
Perfect fourth	18px	1.333	Confident, magazine-style	Body size grows; check measure at desktop
Augmented fourth	16px	1.414	Strong marketing hierarchy	Long-form reading can feel oversized at desktop
Golden ratio	16px	1.618	Dramatic, hero-led	Body sizes often need overrides to stay readable

Whichever scale you choose, document the base size, the ratio, and the rounding rule (whole pixels, half pixels, or decimal pixels). Without a rounding rule, developers will round differently per breakpoint and your rhythm will drift.

Translate the scale into tokens, not just numbers

Designers should not hand off “48px.” They should hand off a token like font.size.heading.lg that maps to 48px at desktop. Tokens are the bridge that lets a system survive a redesign. Decide on three layers:

• Primitive tokens: raw values such as 12, 14, 16, 18, 24, 32, 48, 64.
• Alias tokens: roles such as text.body.md, text.heading.lg, text.caption.sm.
• Component tokens: usage such as button.label, card.title, nav.link.

Engineers consume the alias or component token; designers can rebalance the primitive values without touching code. This is the same idea behind the design systems approach used on mature product teams.

Specify fluid sizing with a real formula

Stepped breakpoints are the easiest way to ship responsive typography and the easiest way to ship visible jumps. Fluid sizing smooths the in-between. The modern CSS primitive for this is clamp(), with the form clamp(min, preferred, max). The “preferred” value is usually built with a linear interpolation between two viewport widths.

Token	Mobile (375px)	Desktop (1440px)	CSS clamp()	Notes
text.body.md	15px	17px	clamp(0.9375rem, 0.86rem + 0.32vw, 1.0625rem)	Body should grow only slightly
text.heading.lg	32px	56px	clamp(2rem, 1.4rem + 2.5vw, 3.5rem)	Hero headline, allow strong growth
text.caption.sm	12px	13px	clamp(0.75rem, 0.73rem + 0.1vw, 0.8125rem)	Captions should never crowd UI
text.display.xl	40px	88px	clamp(2.5rem, 1.5rem + 4.5vw, 5.5rem)	Marketing hero, widest range

For each token, give developers the min, the max, the viewport pair, and the exact clamp() string. A spreadsheet with these four columns is often the most useful handoff artifact in the entire process.

Define the measure, not just the size

Line length (the “measure”) is what makes body copy readable. Designers routinely set a 65-character target and assume developers will preserve it. They will not, unless the spec says so. Specify three things:

• Optimal measure in characters per line (commonly 50 to 75 for body).
• Minimum and maximum width of the text container, in pixels or in ch units.
• Whether long-form containers should cap with max-inline-size or a grid column.

Using ch units ties the measure to the actual glyph width of the body face, which is more robust across fonts than pixel widths. The same idea shows up in any mature website typography reference.

Lock the vertical rhythm

Vertical rhythm is the baseline grid that body text sits on. When the type size changes, the line height should change with it, ideally in proportion. A simple rule that holds up:

1. Pick a baseline unit, often 4px or 8px.
2. Express every line height as a multiple of that unit (1.25x, 1.5x, 1.75x).
3. Snap margins and padding of type-bearing elements to that same grid.

Hand the developer the baseline unit, the body line height, and a one-line rule: “all block margins on type tokens must be a multiple of the baseline.” That single sentence prevents most rhythm drift between Figma and the browser.

Write the spec doc the way engineers read it

A typography handoff works best as a single page with predictable sections. Suggested structure:

• Scope: which surfaces and components the type system covers.
• Tokens: a table of alias tokens with size, line height, weight, letter spacing, and case.
• Fluid ranges: clamp() values per token, with the viewport pair used.
• Measure: container width rules for body, headings, and UI.
• Vertical rhythm: baseline unit, line height multiples, spacing rules.
• Font loading: file formats, weights shipped, fallback stack, FOUT vs FOIT policy.
• Accessibility: minimum contrast, minimum touch target, minimum size, zoom behavior.
• Open questions: anything unresolved, named owner, target date.

Keep it short enough to read in ten minutes. Anything longer will be skimmed and misunderstood.

Decide the font loading strategy up front

Responsive typography breaks in production when custom fonts swap in late. The designer must specify:

• Which weights and styles are actually used (drop the rest, they cost bandwidth).
• File format priority (woff2 first), with subsetting for Latin or other scripts.
• Fallback font stack with metrics that match the custom face as closely as possible.
• Whether to use font-display: swap, optional, or preloading.

The Wikipedia entry on web typography is a useful orientation point for terminology if the team is new to the area.

Accessibility checks that belong in the handoff

Responsive typography is an accessibility concern as much as a visual one. Bake these checks into the spec, not into a “we will look later” backlog:

• Minimum body size of 16px on mobile, with 14px allowed only for true captions.
• Contrast ratio of at least 4.5:1 for body text and 3:1 for large text against any background that ships.
• Real behavior at 200% browser zoom: no horizontal page scroll, no clipped text, no overlapping controls.
• Respect for users who set a larger default font size in OS settings.
• Focus state visibility for interactive text such as links and tabs.

The W3C’s guidance on resize text is a good authoritative source to cite inside the spec so the rules are not just “design opinion.”

A worked example: a 5-step type ramp

Imagine a content site with a 16px body, 1.25 ratio, and a 1440px desktop. The handoff might look like this:

1. Base: 16px body, 1.5 line height (24px on the 4px baseline grid).
2. Scale: caption 13px, body 16px, lead 20px, heading sm 25px, heading md 32px, heading lg 40px, display 50px.
3. Fluid: every token between 375px and 1440px uses clamp() with the preferred value interpolated.
4. Measure: body containers max 68ch; headings can run full width on marketing pages only.
5. Loading: two weights of one variable font, woff2, font-display swap, with a system stack as fallback.

That is enough information for a developer to ship the system on day one and tune it in code review.

QA before merge: a responsive typography checklist

Designers should not hand off a type system and disappear. Joint QA catches issues tokens alone cannot express. Use this short list on every template that ships:

• Render the page at 320, 360, 414, 768, 1024, 1280, 1440, and 1920 widths.
• Test at 100% zoom and 200% zoom at one mobile and one desktop width.
• Read a real article from start to finish; check measure and rhythm with eyes, not tools.
• Switch to dark mode and re-check contrast on every text token.
• Slow the network to 3G and confirm text remains visible during font load.
• Toggle the OS “larger text” setting on iOS and Android and confirm the page still fits.

Common handoff mistakes and how to avoid them

Most typography handoff failures fall into a small set of patterns. Naming them in the spec is a cheap way to prevent them.

Mistake	What it looks like in production	What to specify instead
Pixel-only sizes	Type jumps awkwardly between breakpoints	Fluid clamp() per token with viewport pair
No measure rule	Body lines run 120 characters wide on desktop	Max width in ch units, plus a grid column rule
Inconsistent rounding	Headings look “off” by a half pixel	Single rounding rule per token, written down
No fallback metrics	Layout shifts when web font loads	size-adjust and ascent-override on @font-face
Weight overkill	Page weight balloons, mobile users suffer	List of shipped weights, no extras
Untested zoom	Text clipped or overflowing at 200%	QA pass at 200% on a real device

How this connects to the rest of the design system

Typography rarely fails alone. It usually fails with spacing, color, and components. A few cross-system rules to lock in at the same time:

• Spacing scale shared with type so vertical rhythm is consistent.
• Color tokens paired with type tokens, so contrast is checked per pair, not per color.
• Button, input, and tag components consuming the same alias tokens as content.
• Icon size scale anchored to the type scale (often 1em, 1.25em, 1.5em).

This is the same logic a studio applies to visual identity work: a system beats a collection of one-off decisions.

What to put in the issue tracker after handoff

A clean handoff ends with a small list of follow-ups, not a vague “let me know if anything looks off.” Concrete items might include:

1. Implement clamp() values from the spec table across the marketing templates.
2. Add size-adjust and ascent-override for the primary web font.
3. Audit existing pages for hard-coded sizes and replace with tokens.
4. Add a Storybook story per type token showing the fluid range.
5. Schedule a 200% zoom QA pass on iOS Safari and Android Chrome.

Each item is a real task with a definition of done. That is what makes the handoff stick.

Frequently asked questions

What should a designer include in a responsive typography handoff?

Include alias tokens with size, line height, weight, letter spacing, and case; a fluid range per token (typically a CSS clamp() value with a viewport pair); a measure rule in ch units; a vertical rhythm rule; the font loading strategy; and accessibility checks for size, contrast, and zoom. A short spec with these sections is more useful than a long style guide.

Should I send Figma styles, a PDF, or a code snippet?

All three have a place. Figma styles are the source of truth for tokens, a one-page PDF is the readable overview for the team, and a code snippet (CSS variables or a design tokens JSON file) is what developers actually paste into the codebase. The trick is to keep them in sync: change the tokens, regenerate the other two.

How do I write fluid type sizes if the team is not comfortable with clamp()?

Start with a single token, usually the body or the main heading, and ship clamp() for that one only. Provide the exact string, the viewport pair used, and a screenshot at three widths. Once that lands cleanly, add the next token. Most teams are comfortable with fluid type after they have shipped two or three tokens and seen the result.

What is the difference between a modular scale and a fluid scale?

A modular scale decides the discrete sizes of each type role (for example, 16, 20, 25, 32). A fluid scale decides how each of those sizes behaves between viewport widths. You need both: the modular scale sets hierarchy, and the fluid scale sets motion between breakpoints.

How do I prevent layout shift when web fonts load?

Use a system fallback stack with similar metrics, set size-adjust, ascent-override, descent-override, and line-gap-override on the @font-face rule, preload the woff2 files, and choose font-display: swap or optional based on whether the text is above the fold. This is the most reliable way to keep the page stable while fonts load.

How many font weights should I ship?

As few as the design actually uses. A common pattern is one variable font with two axes (weight and width) covering regular, medium, semibold, and bold. Anything you do not use in a real component should be removed, because every shipped weight costs bandwidth and slows first paint.

What is a safe minimum body size on mobile?

16px is the default most accessibility guidelines point to. You can go down to 14px for true captions and metadata, but body copy, form labels, and button text should stay at 16px or larger. If the brand calls for 14px body, raise the contrast ratio target and test at 200% zoom before shipping.

How do I handle responsive typography in dark mode?

Type sizes and rhythms usually stay the same in dark mode; only colors change. The risk is that a “passing” color pair in light mode fails in dark mode because pure white on a dark background can read as too bright. Test every text token against its dark-mode background and consider a slightly off-white for body copy in dark themes.

What is the role of ch units in responsive typography?

The ch unit is roughly the width of the “0” glyph in the current font. Using ch to set the maximum width of a text container ties the measure to the actual face in use, which keeps line length comfortable even if the font is swapped or the size grows. It is a small change that removes a class of layout bugs.

How do I get developers to actually use the tokens instead of hard-coding sizes?

Make the tokens the path of least resistance. Provide them as CSS variables, document them in the codebase, and add a lint rule that flags hard-coded font-size values. When the system is easier than the shortcut, the shortcut disappears.

A practical next step

Pick one template, build a five-token ramp with clamp() values, write a one-page spec, and ship it with a developer. That single round trip is worth more than any style guide, because it will surface the real questions about measure, rhythm, and loading that the next template will inherit. Once that template is in production, the rest of the site follows the same shape, and the responsive typography handoff stops being a milestone and starts being a habit.

Related reading

• Peak design thinking: how creative teams turn strong ideas into work that ships
• Gaming keyboard choices: switches, layouts, and features that actually matter