Why custom typography falls apart on real content
Typography design mockups are almost always tested on short strings: "Heading", two or three lines of text. As soon as real content gets into a block — long compound terms, paragraphs of several hundred characters — the site's typography stops holding the grid. We break down the specific breaks that are visible on the very first run with production text.
Line wrapping breaks first: a heading without correct breakpoints spills out of the column or breaks mid-word, and justified alignment produces "rivers" of whitespace and uneven density in adjacent lines.
Block overflow manifests not only visually — if a card's height depends on its content, one long line shifts the section and breaks its alignment relative to neighboring ones.
A size scale with discrete steps for each breakpoint creates jumps between sections: a heading in one block looks visually heavier than one with the same meaning in another.
Line height is often set locally in components — sometimes as a multiplier, sometimes as a hard value — and when a different typeface is substituted, lines begin to "breathe" differently, and the vertical rhythm of sections falls apart.
Text readability suffers last, but is noticed most. A line longer than 90 characters makes you lose the beginning of the next one; a lone word in the last line of a paragraph and a preposition at the end of a column finish off the rhythm.
User page zoom adds another layer: a layout designed for a single width overflows at intermediate values and pushes blocks down.
How this is addressed — from hyphenation and a continuous scale to line-height rules for each component.
What changes after the rework: speed, readability, resilience
A unified scale eliminates manual font-size selection in each block: sizes, line spacing, and margins are defined by a set of variables rather than duplicated across styles.
Only 6–8 text sizes remain instead of three dozen random values — this is visible in the number of unique rules and in the weight of styles sent to the browser.
Fewer values mean fewer recalculations during rendering, and text appears all at once rather than being progressively built up as styles are applied.
Readability stops depending on screen width. Line length stays in the 60–75 character range, body text line spacing is around 1.5, and headings are tighter so they read together with the following paragraph. Text and background contrast is checked against an accessibility threshold, not by eye.
Responsive typography is built on smooth size changes between screen boundaries, not on a separate set of rules for each resolution. Intermediate widths — a tablet in portrait orientation, a large phone — do not fall into small or clipped text. There are fewer breakpoints, and behavior between them is predictable.
Vertical rhythm maintains a common step: spacing between a heading, paragraph, list, and callout is a multiple of one value, so blocks neither stick together nor drift apart.
Together with a glyph subset and a reduced set of typefaces, this speeds up first text render and reduces layout shift when the font is swapped.
Font loading methods and typographic scale options
The choice between self-hosting fonts and external loading is decided not by taste but by requirements for control over loading. Self-hosting gives ownership of the font subset, caching, and the font-display rule, but requires monitoring file weight and licenses.
External hosting is connected with a single line, but adds a third-party domain to the critical path of first screen rendering.
A typographic scale is built either as a fixed set of steps or as a continuous function of screen width. Below are alternatives that teams actually choose between at project start.
| Option | When it fits | Limitations |
|---|---|---|
| Self-hosting fonts with a subset for the required alphabet | One or two base styles, predictable rendering matters | Files must be updated and the license monitored for each style |
| A variable font in one file | Many weight degrees, smooth transitions between weight and italic | The file is heavier than a static one; older browsers need a fallback |
| System font stack | Speed and zero delay matter more than a unique typeface | Rendering differs across platforms; the brand loses recognition |
| Modular scale with fixed steps | Simple interface, two or three text sizes | At non-standard widths, gaps appear between steps |
Modular scale with smooth recalculation via clamp() |
Many content types, responsive from mobile to wide screen | Harder to debug: the size cannot be read directly in the mockup |
How typography work is structured: stages from audit to handoff
Custom typography stops "drifting" only when it is described as a system: the size scale, line spacing, and vertical rhythm are set once and reused.
That is why the work proceeds sequentially — from an inventory of current styles to a document by which typography can be reproduced without us.
- Typography audit. We collect all styles from live pages and mockups: font sizes, weights, line heights, spacing before and after blocks. We note where values are set manually and have diverged between sections.
- Scale schema. We calculate a modular scale from the base text size, tie headings to a coefficient and grid step. Here we also determine how the scale changes at each screen width breakpoint.
- Typography styles. We describe them as named entities: size, line height, tracking, weight, vertical spacing. Components reference these values rather than numbers — editing one place changes the entire interface.
- Font setup and loading. We select typefaces and subsets, load them from our own domain, configure fallback, and eliminate layout jank during loading.
- Device testing. We look at real screens and browsers: wrapping, clipping of ascenders/descenders, "orphans" in headings, behavior under system text scaling and in dark theme.
- Documentation handoff. We deliver a style table, usage rules, a memo for content editors, and a list of places for regression. New blocks are then assembled according to these rules.
Style kit, scale variables, and edit regulations
Delivering typography is not a picture or a set of beautiful headings, but a working system that the client uses on their own.
Therefore the kit includes everything needed for edits without our involvement: from scale variables to rules by which a new employee will assemble a page just like the reference one.
- Typography style set. Headings of all levels, lead, body text, captions, quotes, lists, tables, and footnotes — each with defined line spacing, spacing before and after, hyphenation rules, and hanging punctuation.
- Scale variables. Sizes, line heights, spacing, weights, and contrast pairs are moved into variables tied to responsive breakpoints: editing one value rebuilds the entire site, not a single page.
- Usage rules. Where each style is appropriate, how many heading levels are allowed per page, how to format nested lists and long image captions.
- Reference layout. A reference page that brings together all elements at once — from the first heading to a table and footnote; any new layout is checked against it.
- Edit regulations. Who changes scale values and in what order, what is checked before publication, how the reason for a change is recorded, so that six months later it is clear where the current value came from.
- Instructions for editors. A step-by-step document in plain language: how to add material, choose the right style, what to do with a heading longer than a line, and where to turn if the layout does not come together.
- Acceptance checklist. Checkpoints for responsiveness and contrast: testing on narrow screens, behavior when system font size is increased, readability of text over images.
All of this sits next to the code and is updated along with it, so typography does not drift across pages over time. Describe the task — we will return with an estimate and work plan.
Case study: a portal with heterogeneous content and a broken grid
The portal was assembled by different teams: the news section had its own layout, the catalog had its own, and the reference pages had a third. The content was heterogeneous: long texts with callouts, comparison tables, cards with long names.
Headings spilled out of containers, tables stretched the page, and the grid was fixed separately in each section.
At the start, we calculated how many pages actually broke: in 38% of templates, text overflowed the container at at least one breakpoint. Fixing a layout took an average of 90 minutes — values were selected anew, and there was no common scale.
What we changed
We assembled a unified scale and fixed it in variables: font size, line height, letter spacing, and vertical margins became common to all sections. The scale interpolates between breakpoints — sizes are calculated from screen width rather than switched in steps.
We took Inter in its variable version as the basis: one typeface for the entire portal, different styles instead of a second font.
Overflow was addressed with rules, not prohibitions: a minimum size at the lower bound of the range, line length limits, hyphenation of long words and SKUs, and tables scroll within their own area without stretching the page. The rules live in a common layer, so a new section inherits the behavior.
What we achieved
The share of pages with overflow dropped from 38% to 2%. Layout fixes decreased from 90 to 25 minutes: a token changes, not values across sections. Six sections with different grids were reduced to one — columns, margins, and heading rhythm now match.
How does custom typography differ from an off-the-shelf font kit?
An off-the-shelf font kit is a typeface with assembled styles and a clear license. It is enough when a site has one page template and a standard grid: we load two or three styles, set a base size and scale coefficient — typography behaves predictably on all screens.
Limitations appear at scale. Third-party metrics do not match your grid, large headings require manual tracking adjustments, and extra language subsets add weight to the build.
A ready-made kit like Inter covers the interface but does not solve identity and multilingual layout tasks.
Custom typography begins where the scale is designed for the content.
An engineer sets a modular scale — coefficient 1.2–1.333 for interfaces and around 1.5 for text pages — separate line-height and tracking rules for large and small font sizes, and smooth transitions between screens instead of stepped jumps.
Missing glyphs and local styles are added to the font, and fallback metrics are added to the styles so the layout does not jump while the file loads.
Rework timelines differ by an order of magnitude. We implement a ready-made kit in a few days: loading, scale, checking hyphenation and contrast.
A custom system takes weeks: auditing current styles, designing the scale and rules, refining glyphs, and a reference page with all states.
The criterion is simple: if there are fewer than five content types and the brand does not conflict with a standard typeface, a ready-made kit is enough. If there are dozens of pages and several languages, a custom system works more precisely.
Technical questions asked before the start
These doubts come up on almost every project, and almost all of them are resolved at the scale design stage — later rework affects layout, components, and the build. Below are four questions that most often slow down approval, with answers from our engineers.
We do not guess: we read the license before layout, and test font behavior on real texts — long headings, narrow columns, tables — not on a demo paragraph from a mockup.
Which font licenses need to be considered?
We distinguish between free and commercial: for the latter, styles, domains, and impression volume are counted, not just the fact of purchasing a file.
We check this before layout — we record which styles the scale actually needs, assemble a subset based on the glyphs used, and host the files on our own domain so we do not depend on someone else's distribution.
How do you set up word hyphenation so the text does not "tear"?
Automatic hyphenation requires a correct language attribute on the document and dictionaries for it — without them, the browser either does not hyphenate or breaks words poorly.
For narrow columns, we add emergency hyphenation for long words; for headings, line balancing; and we manually mark terms without a dictionary using soft hyphens.
What changes in dark theme?
Dark theme is not a color inversion. Thin styles on a dark background appear bolder and "blur", so for it we select a weight one step lower and separate line-height values.
Plus we check contrast against accessibility requirements and provide a toggle that respects the system setting.
How does typography behave when pages are printed?
Printing is a separate mode: we disable dark theme, otherwise the page turns into excessive ink consumption and unreadable blocks. We set sizes in typographic units, show link addresses, prohibit breaks inside headings and cards, and enable a serif font for long documents.
What to send to start and how we will return with an estimate
So that the estimate is based on facts and not guesses, a few source materials are enough to start. The more complete the picture of fonts, grid, and content, the more accurate the work plan and the fewer edits during layout.
- the address of the current site or test stand and a list of pages where typography already raises questions;
- font files with licenses and a list of domains where use is permitted;
- mockups with text styles or an export with sizes, margins, and line heights;
- brand book or typesetting rules: typefaces, styles, font sizes, hyphenation, heading behavior;
- screen resolution and device type statistics for recent months;
- a description of the platform and current approach to styles: theme, build, design variables;
- accessibility and localization requirements if the site has more than one language.
After that, we review the materials and return with a work plan: which set of scales and styles is needed, how they are loaded, and in what order we roll them out across pages.
Review takes one to two business days; the estimate comes together with the plan — stages, timelines, and what is required from you at each step.
If some source materials are missing, we will gather what is missing ourselves and separately note in the plan which decisions were made on our initiative.
