Recover an existing scale, don't reverse-engineer it by hand (dembrandt engine, optional). If a brand already has type on the web,

get_typography

returns the real font sizes, weights, and line-heights computed off the live DOM — infer the underlying ratio from those, then regularise it with the method below, instead of guessing which sizes were intended. See

extract-design

.

base = 16px

1.25

• 16px — standard body text, the default base
• 14px — acceptable for secondary UI text (labels, captions, metadata) used sparingly
• Below 14px — do not use. Even at high DPI, sub-14px text fails WCAG contrast requirements for normal text and creates accessibility issues.

step 0

• May go below 16px — a fixed whitelist of glanced-at roles: timestamps, captions, table metadata, helper text, fine print, badge labels.
• Never — body copy, primary labels, list item titles, anything actually read to do the task.

• Body and default text: keep tracking at

  0

  . Adding it to running text slows reading and makes the type feel loose.
• Uppercase and small labels: the one place tracking helps, since capitals are visually tight. Cap it at

  0.04em

  , and reach for that only when the label genuinely needs air.
• Pattern: zero on lowercase body, at most a hair (

  ≤ 0.04em

  ) on uppercase labels — never a blanket value. Over-tracking reads as dated, not premium.

• Capitalization: Use uppercase (

  text-transform: uppercase

  ) for small, lower-level headings (H4–H5) to give them visual weight without needing large sizes.
• Letter Spacing: When using uppercase or bold headings, add at most a hair of

  letter-spacing

  (

  ≤ 0.04em

  ) — and only when the heading genuinely needs the air. Keep it subtle; over-tracking reads as dated, not premium.
• Color: Use your brand primary colour or a slightly muted grey for secondary headings to differentiate them from the main black/dark-grey text.
• Style: Use italics or subtle underlines for supplementary or metadata-style headings.

• Simplicity: H1–H3 is enough to cover the page title, section titles, and sub-sections.
• H4–H6 is a complexity smell, not a typography problem. If you find yourself reaching for H4, H5, or H6, the page is trying to do too much. Adding smaller heading levels only hides the symptom. Read it as a signal and make a structural decision instead:
  • Split — the page is really two features, or an in-page sub-page. Break it across pages or a modular structure (sidebar, tabs, master-detail).
  • Remove — the deep section may not earn its place at all.
  • Simplify — flatten the sub-hierarchy so it fits within H1–H3.
  • Hide behind an opening/closing element — push secondary content into a modal, accordion, or panel (see

    information-architecture

    ).

• Lines that are too long make it hard for the eye to find the start of the next line.
• Lines that are too short break the reading rhythm and create distracting "rags."

• Body text: line-height 1.4–1.7, never below 1.4 for multi-line copy. WCAG SC 1.4.12 also requires text to stay readable when users override line-height to at least 1.5, so design with that headroom.
• Headings: large type needs less leading — tighten to 1.1–1.25 as size grows, or the lines drift apart and stop reading as one unit. Leading and size are inversely related.
• Fix the cause, not the symptom: if a line of body text feels hard to read, widen the leading or narrow the measure — don't just shrink the font. The three move together.

line-clamp

-webkit-

-webkit-box

.card-description {
  display: -webkit-box;
  -webkit-box-orient: vertical;
  -webkit-line-clamp: 3;
  line-clamp: 3;
  overflow: hidden;
}

.card-title {
  white-space: nowrap;
  overflow: hidden;
  text-overflow: ellipsis;
}

min-width: 0

min-inline-size: 0

• Provide a

  title

  attribute (or accessible tooltip) carrying the full text, or
• Link to a detail view / "Read more" where the complete content lives.

• Use active voice. "Get started" instead of "Getting started is easy."
• Be punchy. Use clear, descriptive labels that promise a result.
• Consistency. Use the same terms for the same actions throughout the product.

• Desktop → wider ratio (e.g. 1.25–1.333): large contrast between H1 and body
• Tablet → moderate ratio (e.g. 1.200): scale pulls in
• Mobile → tight ratio (e.g. 1.125): H1 is notably smaller, body is unchanged

clamp(MIN, PREFERRED, MAX)

:root {
  --text-body: 1rem;                         /* the floor stays fixed */
  --text-h1: clamp(2rem, 1.5rem + 3vw, 3.5rem);
}

• The

  MIN

  is the mobile size, the

  MAX

  is the desktop size — the same floor/ceiling thinking as the stepped scale, just interpolated.
• Apply

  clamp()

  to the top of the scale (headings, display). Keep body and labels at a fixed size — readability has a hard minimum, so the floor must not move.
• Include a

  rem

  term in the preferred value (e.g.

  1.5rem + 3vw

  , not

  3vw

  alone) so the text still responds to user zoom and root font-size — a pure

  vw

  value breaks zoom accessibility.

• Are all font sizes derived from a single base + ratio?
• Is the base size 16px or larger?
• Is 14px used only for secondary/metadata text, never for body copy?
• Is nothing below 14px used anywhere in the UI?
• Counting distinct sub-16px text roles on a screen, are there only a few (≤3) and all from the secondary whitelist — never reading content?
• Is body letter-spacing 0, with uppercase-label tracking capped at

  0.04em

  and used only when air is needed?
• Does light-on-dark text use a slightly heavier cut to compensate for halation?
• Is monospace scoped to technical content, never used as a default or with uppercase?
• Is there at least 3–4 distinct steps between body text and the largest heading?
• Are adjacent steps (e.g. body vs. label) different enough to be distinguishable at a glance?
• Are font size tokens named by role (

  --text-body

  ,

  --text-h1

  ) or step (

  --text-base

  ,

  --text-2xl

  ), not by raw pixel value?
• Does the chosen ratio suit the UI density? (tight ratio for data-heavy UIs, wider ratio for marketing)
• Is body text line length between 45–75 characters?
• Does body line-height scale with the measure (≈1.4 narrow → ≈1.6+ wide), staying ≥1.4 and leaving 1.5 override headroom for WCAG 1.4.12?
• Is heading leading tightened (≈1.1–1.25) as size grows, so large type still reads as one unit?
• Is line-clamping used to keep grid/card layouts consistent?
• Does clamped text keep a path to the full content (

  title

  /tooltip or detail view), and is must-read content never clamped?
• If fluid type (

  clamp()

  ) is used, is it applied only to the top of the scale, with a

  rem

  -based preferred term so zoom still works?
• Are editorial roles like pre-titles and lead text used to improve scannability?
• Are headings differentiated by more than just size (e.g., color, case, spacing)?
• Is the heading hierarchy limited to H1–H3 per view where possible?