Responsive typography uses CSS media queries to jump abruptly between two hardcoded sizes at a fixed breakpoint — for example, font-size: 24px below 768px and font-size: 48px above it. At exactly 767px you get 24px. At exactly 768px you get 48px. The jump is instantaneous and jarring.

Fluid typography uses the CSS clamp() function to make text grow or shrink continuously as a smooth linear function of viewport width — with no breakpoints at all. At 320px you get your minimum. At 1440px you get your maximum. At every single pixel in between, the font is mathematically exactly right. No jumps. No awkward in-between states. This completely eliminates the “tablet gap” where devices at 600–1024px are served an oversized mobile size or an undersized desktop size.

A modular type scale is a set of font sizes generated by repeatedly multiplying a single base size by a constant ratio. The ratio governs how dramatically each step grows from the previous one. For example, with a base of 16px and a ratio of 1.25 (Major Third): step-0 = 16px → step-1 = 20px → step-2 = 25px → step-3 = 31.25px → step-4 = 39px.

Using ratios creates visual harmony — the same mathematical relationship between each size creates a sense of rhythm and hierarchy, similar to musical intervals (which is why ratios like Perfect Fourth 1.333 and Golden Ratio 1.618 appear in both music theory and typographic design). This tool computes two separate scales — one for mobile with a tight ratio, one for desktop with a dramatic ratio — and wraps each pair in a clamp() to interpolate between them fluidly.

In this generator, step 0 is your base body size — typically 16–20px. Positive steps (step-1, step-2, step-3…) are progressively larger sizes used for subheadings, headings, display text, and hero text. Negative steps (step-1, step-2…) are sizes smaller than your body, derived by dividing the base by the ratio rather than multiplying.

Negative steps are essential for a complete type system: --step--1 is ideal for image captions, form helper text, and timestamps (typically 12–14px). --step--2 is for legal fine print, metadata, and badge labels (10–12px). Be cautious — on mobile with a ratio of 1.250+, step-2 can drop below 10px and become illegible. Always verify negative steps against the WCAG minimum column in the Resolution Table.

The CSS clamp(MIN, PREFERRED, MAX) function returns: the value PREFERRED, but never smaller than MIN and never larger than MAX. For fluid typography, the formula to derive the three arguments from your viewport and size settings is the slope-intercept method:

1. Convert to rem: minR = minPx / rootPx, maxR = maxPx / rootPx
2. Calculate slope: slope = (maxR − minR) / (maxVp/rootPx − minVp/rootPx)
3. Calculate y-intercept: yi = minR − slope × (minVp / rootPx)
4. Build PREFERRED: slope × 100vw + yi rem
5. Final output: clamp(minR rem, slope×100vw + yi rem, maxR rem)

Worked example — 16px at 320px viewport to 20px at 1440px, root 16px: slope = (1.25−1)/(90−20) = 0.003571 → vwCoeff = 0.357 → yi = 1 − 20×0.003571 = 0.929rem → clamp(1rem, 0.929rem + 0.357vw, 1.25rem)

A dual-ratio scale assigns a conservative ratio to mobile and a dramatic ratio to desktop. This solves a critical problem: applying the Golden Ratio (1.618) to 6 steps produces a top step of ~110px at 16px base — magnificent on 4K but physically wider than an iPhone screen before a single word fits.

How it works: For each step N, the engine computes minPx = baseMin × ratioMin^N (tight mobile ratio) and maxPx = baseMax × ratioMax^N (dramatic desktop ratio), then wraps them in clamp(). Result: your H1 might be 32px on mobile (readable) and 90px on desktop (impactful) — with perfect scaling at every intermediate viewport.

Recommended pairings: Mobile 1.125 (Major Second) + Desktop 1.414 (Augmented Fourth) for marketing sites. Mobile 1.067 (Minor Second) + Desktop 1.250 (Major Third) for dense dashboards. Mobile 1.125 + Desktop 1.618 (Golden Ratio) only if you keep step count ≤ 5.

Typography is multi-dimensional. Large display text requires tight leading and tracking; small body text requires loose leading. This generator auto-calculates companion tokens for every step:

Line-height interpolates linearly from lhMax (for negative steps) down to lhMin (for the highest positive step). Default: 1.75 for body copy down to 1.1 for display headings. The formula maps each step's position in the range [−stepsNeg, stepsPos] to the [lhMax, lhMin] line-height range.

Letter-spacing interpolates from lsBody (for step 0 and below) to lsHeading (for the top step). Default: 0em body, −0.02em headings — mimicking the optical tracking adjustments used by Apple, Google, and IBM in their design systems. Both values are exported as part of every token format (CSS custom properties, Tailwind fontSize config, SCSS map, Figma JSON, and W3C tokens).

Using pixel values inside clamp() — e.g., clamp(16px, 2vw, 32px) — violates WCAG 2.1 Success Criterion 1.4.4 (Resize Text, Level AA), which requires that text can be resized up to 200% without loss of content or functionality.

Here is exactly why it fails: A visually impaired user sets their browser default font size to 24px. CSS rem units are relative to this setting — 1rem = 24px for them. But 16px is an absolute unit — it ignores browser settings entirely. Your clamp(16px, ...) locks their minimum at 16px regardless of their preference, preventing them from exercising their accessibility setting.

This generator always outputs boundaries in rem units. When a user has set their browser font to 24px, your clamp(1rem, ...) becomes clamp(24px, ...) on their device, correctly scaling up. This achieves WCAG 1.4.4 compliance automatically. The WCAG checker in the Resolution Table flags any step where the minimum clamp value (at your minimum viewport) falls below your configured pixel threshold.

WCAG 2.1 does not specify an absolute minimum pixel size — the standard is relative (200% resizability). However, practical readability research and the W3C Accessibility Guidelines Understanding documents suggest 14px as the absolute floor for body text and 9px for decorative/supplementary text. Major browsers flag sub-11px text as a usability concern in Lighthouse audits.

This tool's WCAG checker evaluates each step's minimum clamp value — the size that will render at your smallest viewport (e.g., 320px) — against your configured threshold (default: 11px). The threshold is configurable in the Advanced tab via the WCAG Min slider so you can match your project's specific accessibility requirements. Flagged steps appear with a red ⚠ warning in the Resolution Table. The most common failures are --step--2 with aggressive ratios, where a 1.414 ratio applied to 16px base produces a step-2 value of ~8px.

Standard vw-based fluid typography scales text relative to the browser window width. This breaks in component-driven layouts: a card in a 3-column CSS Grid on a 2560px monitor has a container ~800px wide, but its vw-based heading sees the full 2560px viewport — producing enormous text that overflows the card.

Container Query mode replaces vw with cqi (Container Query Inline units). The text now scales relative to its nearest sized container width, not the viewport. This makes components truly modular and reusable. A card heading will scale correctly whether it's in a sidebar or a full-width hero.

Requirements: The parent element must have container-type: inline-size (or size) applied. Browser support is excellent: Chrome 105+, Firefox 110+, Safari 16+ (96%+ global support as of 2025). Use vw for page-level typographic elements like hero sections and article bodies. Use cqi for reusable components like cards, sidebars, and modals.

CSS Variable Prefix (default: --step) controls the naming of your generated custom properties. Changing it to --fs gives you --fs-0, --fs-1, etc. Changing to --type gives --type-0. This matters for design system consistency — if your existing system uses --text-size-, change the prefix to match and the output drops in as-is with zero renaming.

Root PX (default: 16) tells the calculator what 1rem equals in pixels when performing the slope-intercept math. It does not change what gets output — the output is always in rem. It only affects the mathematical conversion from the pixel values you enter in the controls. If your project sets html { font-size: 18px; }, change Root PX to 18 so the generated clamp() values precisely hit your intended pixel sizes at each viewport boundary. Verify by checking the Resolution Table — it shows the rendered pixel size at 4 viewport widths.

The Slope Chart plots the rendered pixel size of each type scale step against viewport width (x-axis: your min-VP to max-VP range, y-axis: rendered size in pixels). Each coloured line represents one step. A healthy chart shows all lines parallel and non-overlapping — larger steps stay above smaller steps at every viewport width.

Crossing lines mean a higher-numbered step is temporarily rendering smaller than a lower-numbered step at some viewport width. This creates an incoherent visual hierarchy at that viewport. It typically happens when your mobile ratio is much tighter than your desktop ratio with many steps — the aggressive desktop ratio causes high steps to “outrun” their slope relative to lower steps.

To fix crossing lines: (1) Reduce the number of positive steps — fewer steps = less opportunity to cross. (2) Bring your mobile and desktop ratios closer together. (3) Increase your base size gap (baseMax − baseMin) to give more room for the slopes to separate. The Resolution Table will also show numerically where crossings occur.

Copy the CSS Variables export and paste it into your project's root stylesheet (typically :root { }). Each custom property is then available globally:

:root {
  --step--2: clamp(0.64rem, 0.60rem + 0.19vw, 0.78rem);
  --step--1: clamp(0.80rem, 0.75rem + 0.24vw, 0.98rem);
  --step-0:  clamp(1rem, 0.93rem + 0.36vw, 1.25rem);
  --step-1:  clamp(1.25rem, 1.14rem + 0.55vw, 1.56rem);
  --step-2:  clamp(1.56rem, 1.38rem + 0.93vw, 1.95rem);
  --step-3:  clamp(1.95rem, 1.65rem + 1.51vw, 2.44rem);
}

Then apply them with standard CSS: font-size: var(--step-3);. For Tailwind, paste the Tailwind Config export into your tailwind.config.js under theme.extend.fontSize. For SCSS, use the SCSS Map export with the included @mixin fluid-type(). All exports include line-height and letter-spacing alongside font-size.

Figma does not natively render CSS clamp() — designers work with static frame sizes. The recommended workflow for design-development alignment is:

1. Designer identifies pixel values: On the 375px mobile frame, measure the heading size (e.g., 32px). On the 1440px desktop frame, measure the same heading (e.g., 72px).
2. Enter those values as base sizes and viewport bounds in this generator.
3. Verify in the Resolution Table — confirm the clamp() output hits exactly 32px at 375px and 72px at 1440px viewport.
4. Export Figma JSON — click “Export Tokens” and select the Figma JSON tab. This outputs a structured JSON compatible with the Tokens Studio Figma plugin.
5. In Figma: Open Tokens Studio → Import → paste the JSON. Token values are now linked to your Figma text styles.

Note: Figma will show the raw clamp() string as the token value, not a resolved number. This is expected — the token is the source of truth consumed by the CSS build, not Figma's renderer.

The W3C Design Tokens Community Group (DTCG) format is a standardised JSON specification for design tokens that enables platform-agnostic token distribution. Each token has a , a , and an optional .

Exporting to W3C format lets you pipe your fluid type scale into build pipelines such as:

• Style Dictionary (Amazon) — transforms tokens into CSS, Android XML, iOS Swift, and more
• Cobalt — W3C-native token transformer with multi-platform output
• Specify — syncs tokens between Figma and code repositories automatically
• Theo (Salesforce) — transforms into any platform format

The W3C export from this tool includes font-size (as the clamp() string), line-height, and a human-readable for each step. This makes your fluid typography scale a true single-source-of-truth that can be consumed by both designers (via Tokens Studio) and developers (via Style Dictionary pipelines).

There are four common reasons fluid typography stops working on the live site:

1. A competing font-size rule overwrites it. If a component's CSS sets a static font-size: 18px after your custom property assignment, it wins. Check browser DevTools → Computed tab for the element — struck-through declarations indicate overridden rules.
2. The custom property is applied to the wrong element. CSS custom properties cascade — if --step-2 is defined in :root but you apply font-size: var(--step-2) inside a Shadow DOM, the variable won't be inherited. Define tokens at a level that reaches your component.
3. The root font-size is different from 16px. If your CSS has html { font-size: 62.5% } (a common 10px trick), 1rem = 10px. Your clamp output is based on 16px rem, so all sizes will be 62.5% of what you expect. Either remove the root font-size override or set the Root PX setting in the Advanced tab to 10.
4. Browser zoom vs font size preference. Browser zoom scales everything equally (including vw units). User font size preference only affects rem. Both are supported by this tool's output.

Two edge-case guards prevent the generator from producing invalid or nonsensical clamp() output:

Static Guard: If your minimum and maximum pixel sizes are equal (or differ by less than 0.001px), the generator detects that no fluid scaling is needed and outputs a plain rem value instead of clamp(X, Yvw + Zrem, X). A zero-slope clamp is syntactically valid but wasteful and confusing — the plain rem is cleaner and semantically correct.

Direction Guard: If maxPx < minPx — meaning your font shrinks as the viewport grows — the generator detects the inversion and swaps the clamp bounds. The output produces a valid decreasing clamp: clamp(maxR, slope×vw + yi rem, minR). This is intentional behaviour useful for decorative elements that should be proportionally smaller on larger screens (e.g., small caps labels, icon labels). Both guards are applied per-step, so a scale can have some steps growing and some static without any issues.

As of mid-2025, clamp() has 97%+ global browser support (Chrome 79+, Firefox 75+, Safari 13.1+, Edge 79+). It is safe to use in production without fallbacks for all modern projects.

For legacy enterprise environments supporting Internet Explorer 11 or older Safari (pre-13.1), add a static fallback rule immediately before the fluid rule in your CSS:

h1 {
  font-size: 2rem;                        /* IE11 fallback */
  font-size: clamp(1.5rem, 3vw + 1rem, 3rem); /* Modern */
}

CSS parsers in unsupporting browsers silently ignore rules with unknown functions. The fallback rule is parsed first and applies. The fluid rule is then parsed — if the browser supports clamp(), it overrides the fallback; otherwise the static rem value holds. The CSS Variables export from this tool does not include static fallbacks by default, so you would need to manually add them if you need IE11 support (which is now below 0.3% global traffic).