A practical guide

From two type sizes to a bounded rule.

A fluid font-size rule answers one question: what should happen between two widths you have already chosen? It cannot choose good typography for you. This guide shows the calculation and the checks that belong around it.

1. Choose anchors with a purpose

Use a narrow width where your small-layout text has been tested, then a wider width where the larger size feels appropriate. Enter CSS pixels, not the physical pixel count printed on a device box. Keep the wide viewport width greater than the narrow one. The font sizes may increase, decrease or remain equal.

Do not use a very large upper size simply because a screen is wide. A card inside a sidebar may stay narrow even when the whole browser grows. The generated vw term follows viewport width; it does not inspect that card. If the component should react to its container, this tool's viewport-only rule is the wrong model.

2. Find the straight line

Call the viewport widths w0 and w1, and their font sizes f0 and f1. The font-size change per viewport pixel is m = (f1 − f0) / (w1 − w0). The intercept is b = f0 − m × w0. A size inside the anchor interval is therefore b + m × w.

One vw represents one percent of viewport width under CSS viewport-unit rules. Multiplying the slope by 100 gives a coefficient for that unit: v = 100 × m. The preferred term becomes calc(b px + v vw), with subtraction for a negative coefficient. The generator inserts the required spaces around the arithmetic operator.

3. Bound the result

The smaller chosen font size is the lower bound and the larger is the upper bound. The exact model is max(low, min(b + m × w, high)). The bounds refer to sizes, not to which anchor is labelled narrow. This distinction matters when the font becomes smaller as the viewport grows.

At each anchor, the exact model returns the entered size. Between the anchors it follows the line. Beyond them it stays bounded. The width-check table includes both anchors, the range endpoints 0 and 100000, and your optional sample without duplicate widths. A width of zero is only a mathematical check, not a useful device claim.

Worked example: a gentle increase

Choose 14 px at a 320 px viewport and 22 px at 1280 px. The rise is 8 px across 960 viewport pixels. The exact slope is 1/120, the intercept is 34/3 px, and the vw coefficient is 5/6. At 800 px, the model gives 34/3 + 800/120 = 18 px.

The exported preferred term uses approximately 11.333333333333 px plus 0.833333333333 vw. The lower and upper bounds remain exactly 14 and 22 px. The model stays at 14 px below the first anchor and 22 px above the second. The long coefficients are a decimal representation of simple fractions; they do not imply that a browser exposes twelve useful decimal places.

Worked example: a deliberate decrease

Keep the widths 320 and 1280, but use 16 px at the narrow width and 12 px at the wide width. The slope is −1/240, the intercept is 52/3 px and the coefficient is −5/12 vw. At 800 px the exact size is 14 px.

The declaration still places 12 px first and 16 px last. Its preferred term subtracts a positive vw magnitude. Writing ordered bounds avoids a contradictory minimum and maximum. A decreasing rule deserves the same content and resize testing as an increasing one; this example is mathematical, not a design recommendation.

Worked example: short, exact coefficients

For 15 px at 375 px and 27 px at 975 px, the slope is 1/50, the intercept is 7.5 px and the coefficient is 2 vw. The declaration is font-size: clamp(15px, calc(7.5px + 2vw), 27px);. At 675 px, the preferred size is 7.5 + 2 × 6.75 = 21 px. This is a useful small check when testing the generated rule in a browser.

What if the sizes are equal?

Two 20 px endpoints describe a constant result. The slope and viewport coefficient are zero, and every sample returns 20 px. Clampcraft emits equal bounds with a constant preferred value. There is no reason to invent a changing viewport term for this case.

Exact arithmetic and CSS export

Plain decimal font sizes are converted to integer fractions before subtraction and division. The exact coefficient panel and downloaded notes retain those fractions. CSS cannot carry every repeating decimal exactly, so exported non-terminating coefficients are rounded to at most twelve fractional places, with ties away from zero. Trailing zeros and negative zero are removed.

For the stated sample range 0–100000 px, this coefficient serialization changes the mathematical result by less than 0.000001 CSS px. That is a bound on the exported equation, not a guarantee about browser computation, displayed computed-style precision, font rasterization or text width. The eight-place size display is also a rounded presentation; consult the exact fraction beside it when comparing arithmetic.

The sample and the preview are different

The sample field asks the calculator about an entered width without changing your window. It can be blank; the rule and anchor checks still work. The visible preview line actually receives the generated font-size value, so its size depends on your current browser viewport. Resize the browser to test that line. Changing only the sample does not emulate a device or resize the preview.

The preview uses the site's system font. Your production font may have different letter widths, line metrics, available weights and fallback behaviour. A readable preview is therefore only one check. Test the actual selector, content and font in your own layout.

Input scope and limits

• Anchor widths: plain whole CSS pixels from 1 to 100000, strictly increasing.
• Font sizes: 0.01–1000 CSS pixels, with at most six fractional places. Ordinary decimal forms such as 15, 15.25 and .5 are accepted.
• Optional sample: a plain whole width from 0 to 100000. An empty sample is unavailable, not zero.
• No exponent notation, comma grouping, signed input, unit suffix, CSS expression or uploaded font. Numeric fields have a defensive 64-character limit.
• This version outputs px and vw only. It does not calculate rem values, container queries, breakpoints, font measurements or accessibility scores.

Invalid input clears the prior declaration, table, sample and preview style. Copy and download are disabled until the current inputs form a valid model. This prevents a plausible old answer from looking like a result for a new, invalid field.

A useful checking routine

1. Check the chosen sizes at both real anchor widths with your production font.
2. Inspect at least one intermediate width and both sides of the interval. Look for wrapping, clipping and awkward neighbouring elements.
3. Test user text resizing and browser zoom. Viewport-only sizing can interfere with expected enlargement; a bounded formula does not establish WCAG conformance.
4. Check the browser and viewport-unit behaviour relevant to your audience. The tool's mathematical sample is not a browser test.
5. Keep the declaration with a note explaining why those anchors were chosen, so later design changes can be evaluated deliberately.

Primary references

The arithmetic and examples above are original explanations of the selected model. CSS function/unit behaviour is grounded in the W3C CSS Values comparison functions and CSS math syntax. These pages form part of a Working Draft. For the separate text-resize concern, consult W3C WAI's Resize Text guidance.

Return to the calculator