Recommend CSS line height for a font size and content type

This CSS line-height recommendation tool turns a font size and a typography role into a practical starting value. Choose body text, heading, or caption, and it applies a common role-specific ratio before returning both the unitless recommendation and its pixel equivalent. It is useful when a design begins with font sizes but has no established vertical-rhythm tokens yet. The result is deterministic, easy to copy into CSS, and intentionally presented as guidance rather than a claim about the unique perfect setting for every font.

Choose the content role before choosing the spacing

Line height should respond to how text is read, not merely repeat one multiplier across an entire interface. Body text usually spans several lines and must support comfortable tracking from the end of one line to the beginning of the next, so this tool recommends a ratio of 1.5. Headings are normally shorter, larger, and often limited to one or two lines; a tighter ratio of 1.2 preserves their visual unity and avoids turning a wrapped title into disconnected blocks.

Captions are smaller but generally brief, so the recommendation uses 1.4, giving compact text enough air without making it dominate nearby media or controls. Select the semantic role that describes the text's actual job. Use heading for titles and section labels that employ display-size type.

Use caption for image notes, figure labels, timestamps, and short secondary annotations.

Understand the returned ratio and pixel value

The recommendation is calculated by multiplying the positive font size in CSS pixels by the fixed ratio for the selected content type. A sixteen-pixel body size uses 1.5 and therefore returns twenty-four pixels. A thirty-two-pixel heading uses 1.2 and returns thirty-eight point four pixels.

The unitless ratio is often the better production value because CSS lets it inherit proportionally when descendants change font size. The pixel result is still valuable for design handoff, static specifications, visual QA, email templates, and token systems that require explicit lengths. Results are rounded to four decimal places so fractional sizes remain useful without exposing floating-point noise.

Input must be a positive finite number; zero, negative numbers, missing values, infinity, and nonnumeric strings produce an invalid-input error. Remember that the returned number represents a recommended line box, not the visible height of a glyph. Fonts distribute ascenders, descenders, and internal leading differently, which is why two typefaces at the same font size and line height can still appear more open or more crowded.

Treat the arithmetic as a reliable baseline for comparison and implementation, then inspect actual rendered text before finalizing a system-wide token.

Test the recommendation in the real layout

After generating a recommendation, place it in the layout where the text will actually appear and test representative content rather than a single polished sentence. For body text, include several paragraphs, long links, emphasized phrases, numbers, and narrow mobile widths. Check whether readers can move between lines without losing their place and whether the paragraph still feels connected as a whole.

For headings, test the longest realistic title at every responsive breakpoint. A ratio of 1.2 often creates a strong display block, but a typeface with unusually tall accents or a heading that wraps to three lines may need more space. For captions, inspect dense cards, image credits, table notes, and localized strings because small text can become tiring when line boxes are compressed.

Also check zoomed views and user-selected font substitutions where possible. Adjustments should become deliberate design tokens rather than scattered one-off CSS declarations. For example, start with the recommended ratio, record a tested exception for a particular display family, and apply that exception consistently to matching components.

This capability does not measure font metrics, line length, language, weight, or rendering environment, so it cannot replace visual review or accessibility testing. Its value is giving teams a sensible, explainable starting point and a repeatable calculation.