Are you choosing hosted fonts or checking owned font files?
Use the Google Fonts lab for its curated hosted families and the inspector for uploaded files. A family name typed into the pairing card does not load its binary.
Elysia Tools
Navigation
Workflow Playbook
Check font coverage, compare heading and body pairs with real copy, configure variable axes, and deliver responsive CSS with verified fallback behavior.
Hubs
This workflow gives a frontend developer or designer a typography handoff for one multilingual page. Collect real copy before picking families: a long heading, a normal paragraph, currency and digits, accented names and the punctuation each locale uses. Inspect owned files with font-file-inspector, keeping their version and required weights beside the coverage report. Coverage by Unicode block is an inventory aid; it does not establish that every glyph or shaping sequence in your copy works. Review the font's deployment terms separately and record the approved source. For suspicious invisible characters or mixed code points, follow unicode-emoji-debugging.
Use webfont-pairing-lab when its curated Google Fonts families fit the brief. It loads those families and emits a hosted import for the selected weights. For an owned face or an existing site stack, use font-pairing-preview-card after making that font available to the host. The card does not fetch binaries from the name alone. An attractive preview may actually be a local fallback, so inspect the rendered font on the target page before accepting it. Keep the text constant while adjusting heading weight, body size and line height; include a long title that exposes cramped wrapping.
If inspection shows fvar axes, use variable-font-axis-instance-and-css-font-variation-settings-builder to compare named instances and chosen coordinates within the supported ranges. Prefer the emitted high-level properties where they express the desired setting clearly. Replace any preview asset reference with the deployed font URL and test that file. For a static family, document which weight file supplies each role. Do not assume a browser-generated bold appearance means that the intended weight was loaded. Save the font file identity, CSS stack and chosen coordinates together so another developer can reproduce the result.
Use css-fluid-typography-clamp-calc to calculate the agreed minimum and maximum size across your viewport bounds. Apply the result to the page, then test both endpoints and an intermediate width. Increase browser zoom and disable font loading to inspect fallback wrapping, button labels and clipped lines. A size formula cannot prove readable reflow. Deliver the CSS, asset source, language samples, tested widths and remaining defects together. If the problem is conflicting selectors or layout rules, use css-authoring-layout-and-cascade-workflows; finish the wider accessibility review with web-accessibility-audits.
Workflow playbook
Inspect uploaded font metadata, Unicode coverage, style flags and axes. Compare the coverage with real language samples and list any required fallback characters.
Use the hosted-font lab for its Google Fonts choices or the pairing card for an already loaded CSS stack. Keep the same real copy while comparing weights and line heights.
Inspect named instances and axis bounds, preview selected coordinates and export CSS. For a static font, retain explicit weight files and skip axis configuration.
Calculate clamp bounds for the agreed viewports, apply the CSS to the real page and manually check actual font loading, line breaks, zoom and fallback behavior.
Use the Google Fonts lab for its curated hosted families and the inspector for uploaded files. A family name typed into the pairing card does not load its binary.
Use the axis builder only when the inspected file contains fvar axes. A static font needs the correct weight files rather than invented axis settings.
Review font coverage and the actual fallback glyph first; investigate unexpected code points with unicode-emoji-debugging before replacing a font.