You've inherited a client website, opened the browser, and found four custom font families loading from different places. One comes from a hosted provider, another sits on the client's CDN, a third appears in a theme stylesheet, and nobody can tell you which license covers any of them. The CSS names look familiar, but the rendered page tells a more complicated story.
That's why how to check fonts on a website shouldn't mean hovering over one paragraph and copying a family name. A dependable audit identifies the face the browser rendered, traces the files that were downloaded, checks how typography affects loading, and separates technical evidence from proof of web usage rights.
Why a Font Check Is Now a Routine Audit
Web fonts went from near-zero adoption as late as 2011 to 82% of desktop pages and 80% of mobile pages in 2020, according to the HTTP Archive Web Almanac's font data. Usage reached about 87% of websites in 2024 and roughly 88% in 2025, while about 72% of websites served at least one font file from their own origin in 2025. The delivery model is no longer simple. A site may combine hosted fonts, self-hosted files, subsets, variable fonts, and system fallbacks.
In an agency handover, the first pass usually starts in Chrome. The developer checks the stylesheet, finds a familiar font-family declaration, and assumes the case is closed. That approach fails when an @font-face rule overrides the declared stack, a requested face falls back because its file failed, or a variable font supplies several apparent weights through one resource.
A proper audit has four layers:
- Identification: Confirm the family, style, weight, and actual rendered face.
- Network payload: Record which font resources the browser requested and downloaded.
- License: Match each deployed face and delivery method to documentary rights.
- Performance: Review request timing, font loading behavior, and visual stability.
Brand teams trigger these reviews after redesigns, site handovers, acquisitions, and template changes. Engineering teams need them when Core Web Vitals regress. Compliance teams need them during periodic reviews or due diligence. Privacy updates can also expose an overlooked hosted font request when a consent process changes how third-party resources load.
The risks are practical: an unlicensed webfont, a render-blocking payload, or a fallback that makes one page look visibly different from the rest of the site. Manual inspection works well for a small number of templates. Larger sites need a scanner, a crawl, or structured asset review, but automation should support confirmation rather than replace it.
Inspecting Fonts with Browser DevTools
DevTools is the best starting point because it shows the browser's final decision, not just what a developer intended to write. Open the page, use the element picker, and select a text node. Press F12, Ctrl+Shift+I, or Cmd+Option+I, depending on your system, then open Computed.
Read the resolved result
Start with the font-family, font-style, font-weight, and font-stretch values on the selected element. Then inspect the rendered-font information available in the Computed view. The declared stack may list several fallbacks, while the browser uses only one face. That distinction matters when a webfont failed, a glyph came from another fallback, or an override changed the effective rule.
Select body, the main heading, a paragraph, navigation, buttons, and any component that uses a different visual treatment. A single hover inspection catches one node and one context. A page-level pass reveals whether the display family appears only in headings, whether a text family is missing on a nested component, and whether a declared weight is being synthesized.
Use the page-wide Fonts panel where your browser exposes it. Select the body element and review the active fonts, then hover a font name to locate the text using it. This is more useful than relying only on stylesheet search because it shows the fonts that rendered across the inspected page. Browser guidance on listing used fonts also highlights the importance of selecting an actual text element, since a non-text selection can hide the rendered-font readout. The browser font inspection workflow is a useful reference for this process.
Check the awkward cases
Inspect iframes separately. A font used inside an embedded document may not appear in the parent page's inventory. Shadow DOM can also hide styles and nodes from a casual document-wide review, so inspect the component boundary and its rendered text directly.
For a quick programmatic check, use the console:
document.fonts.check("16px Brand Family")
Replace Brand Family with the family under review. This confirms whether the browser considers a matching font available for the test string, but it doesn't prove that every weight rendered or that the face is licensed. Treat it as a confirmation signal, not a complete audit.
For a broader practical comparison of inspection approaches, see this font finder tools guide for designers and developers. Browser DevTools remains the evidence source for the live rendering result.
Reading the Network Panel and Performance Signals
The Network panel answers a different question: which font files did the browser request? Reload the page with the panel open, select the Font filter, and record every WOFF, WOFF2, OTF, or EOT request. Include requests from the site origin, a CDN, a hosted font service, and scripts that inject styles after the initial document loads.
Open each request and capture the URL, response size, transfer size, status, initiator, and timing. Compression can reduce transfer size, but a smaller wire payload doesn't make an unnecessary face useful. Compare the files with the @font-face declarations and note resources that were declared but never requested, requested but never rendered, or loaded more than once through different stylesheets.
Font files can affect page speed. In a 2026 Google Fonts performance analysis, sites loading Google Fonts had good mobile Largest Contentful Paint 63.0% of the time, compared with 72.3% without Google Fonts, while overall Core Web Vitals pass rates were 40.3% with Google Fonts versus 43.9% without. The same analysis reported a 9.0-point LCP gap for sites using a font script, with good LCP at 64.4% versus 73.4% without. These figures are documented in the web-font Core Web Vitals analysis.
Watch the waterfall and the text
The waterfall shows whether font requests wait behind CSS, scripts, or other resources. Observe the page from a cold reload and record whether text is invisible during loading, briefly shown in a fallback, or visibly reshaped when the webfont arrives. That behavior distinguishes FOIT, invisible text during font loading, from FOUT, a fallback that remains visible until replacement. The font-display choice can create either a readability problem or a layout-shift problem.
Flag oversized font files, redundant styles, repeated subsets, missing unicode-range hints, and weights that no component uses. Practical web-performance guidance commonly treats compressed font files above 50 KB as a payload warning, so use that threshold as a review trigger rather than an automatic failure. Keep a waterfall screenshot and export a HAR file for client reporting. They provide a baseline that another engineer can compare after a redesign. A focused font subsetting guide can help when the inventory shows unnecessary glyph ranges.
Using Online Scanners and Image-Based Identification
DevTools is efficient on a few templates. It becomes slow when a site has many routes, localized versions, legacy landing pages, embedded applications, and assets that don't expose their typography as live HTML. That's where an indexed scanner can reduce the first-pass workload by crawling pages, reading CSS, and correlating detected faces with their locations.
Hover-based browser extensions are useful for a quick answer on one visible element. They're weaker for whole-page inventory because they don't automatically expose every nested component, hidden state, fallback, or route. A scanner can produce a face list with confidence values and point to the pages where each family appears. It may also reveal a fallback stack whose ordering suggests that the apparent primary face isn't consistently available.
| Method | Best For | Limits |
|---|---|---|
| Manual DevTools | Confirming the exact rendered face on key nodes | Slow across many templates, iframes, and states |
| Browser hover inspection | Rapid checks on visible text | Usually limited to the selected element |
| Indexed page scanner | Building a multi-page inventory and finding repeated or orphaned faces | Can miss unusual declarations and still requires manual confirmation |
| Image matcher | Identifying type in banners, PDFs, and exported artwork | Similar glyph shapes can produce uncertain matches |
| Human review | Confirming obscure faces, altered lettering, and brand-specific details | Takes time and needs a reference library |
AI-based image matchers are fast and broad. They struggle with low-resolution crops, modified lettering, unusual ligatures, and text rendered over busy backgrounds. Human review takes longer but is more reliable when the face is obscure or the artwork includes only a few characters. Treat a visual match as a lead until you confirm it against a live font file, a known specimen, or the original design source.
For a wider design-asset perspective, the Superdesign design system extraction guide is useful when typography needs to be considered alongside colors, spacing, and component patterns. A hybrid process works best: scan first, manually confirm important findings, then preserve the evidence in the handover report. For image-specific workflows, use this guide to finding fonts from images.
Auditing PDFs Images and Zipped Font Sets
The live website is only one part of a brand audit. Agencies often receive PDFs, social tiles, campaign artwork, presentation decks, and zipped brand kits that contain fonts not present in the current CSS. Those files can explain visual drift, expose an old family still used in marketing, or reveal a licensing obligation that the web team never recorded.
For PDFs, run pdffonts against the file to list embedded family names, styles, and embedding details. Use mutool when you need a second extraction path or want to inspect a document that doesn't yield a clean inventory on the first pass. Cross-check each PostScript name against the licensed inventory, not just the friendly family label shown in a design application. A family can contain separate regular, italic, display, and variable resources.
Treat image matches as review signals
Crop a representative text area from a hero banner or social asset and submit it to an image matcher. Record the returned candidates, the crop used, and the confidence score. For this workflow, treat anything below 85% as a manual review item rather than a confirmed match. The threshold is a process rule for your audit team, not proof that an image model has identified the typeface correctly.
Zipped font sets need a file-level inventory. Unzip the archive, record filenames and internal PostScript names, and hash each file against the organization's known-font database. Flag a face that appears in the archive but never appears in the site's CSS, since it may belong to print work, an abandoned redesign, or an undocumented web deployment.
Protect sensitive artwork
Third-party image upload creates a privacy question. Client artwork may contain unreleased campaigns, personal information, or confidential product details. Use a local matcher for sensitive engagements, or obtain approval before uploading assets to an external service. Store the original crop, extraction method, reviewer, and decision with the audit record.
A simple confidence rubric keeps reports consistent:
- Confirmed: Exact rendered or embedded face matched to a known file.
- Strong lead: High-confidence image match supported by glyph and style comparison.
- Review required: Image result below the team's confidence threshold or an ambiguous PDF name.
- Unresolved: No reliable match, incomplete artwork, or unavailable reference specimen.
The PDF font extraction workflow adds useful detail for recovering embedded faces before reconciliation.
Interpreting License and Compliance Signals
A font can render perfectly and still be improperly licensed. @font-face proves that a browser can retrieve a resource. It doesn't prove that the organization bought the right to serve that resource on the observed domain, at the observed traffic level, or through the observed delivery method.
Separate desktop rights from web rights
A desktop license generally covers installing a font on a computer for design work or static outputs. Serving that same font through CSS usually requires a separate webfont license, often scoped by domain or page views. Converting a desktop file into WOFF2 doesn't change the rights attached to the original purchase. The web-font licensing guide explains this distinction and why desktop and web permissions must be checked separately.
This applies whether the file is self-hosted or delivered by a hosted service. Self-hosting a print font on a CDN is still web delivery. A hosted provider may bundle rights, but the agreement can still contain domain, account, embedding, or traffic restrictions. Read the license terms rather than inferring permission from the delivery mechanism.
Foundries and licensing platforms may use separate products or agreements for desktop and web use. A receipt for a design application, a subscription, or a desktop bundle is evidence of acquisition, not automatic proof of website coverage.
Look for operational exposure
Underlicensing can lead to takedown demands, retroactive fees, or an obligation to regularize historical use. One foundry EULA states that unauthorized use may trigger a regularization fee of at least 200% of the license fee that would have been payable for the actual infringement period. That term appears in the foundry EULA, and the exact consequence depends on the agreement and circumstances.
U.S. copyright guidance commonly cited in font licensing materials describes statutory damages of $750 to $30,000 per work infringed, potentially rising to $150,000 per work for willful infringement. Those figures are discussed in font licensing guidance on infringement mistakes. They aren't a prediction of liability, and jurisdiction, facts, ownership, and contract terms matter.
License scope creates another common failure point. A license may cover one website, one domain, or a defined pageview tier, such as a starting tier at 10,000 monthly views per site. Some EULAs prohibit desktop files as webfonts and permit self-hosting only with approved webfont files. Reusing a family on another domain, subdomain, or higher-volume site can therefore require a new license or an upgrade. See the webfont EULA examples for the kinds of restrictions an audit should surface.
Build an evidence packet
Match the technical inventory against:
- CSS and source records: Identify every family, style, weight, file URL, and delivery origin.
- License documents: Match the license name and identifier to the internal font file and foundry record.
- Scope details: Check domains, subdomains, delivery methods, and applicable traffic tiers.
- Ownership sign-off: Ask the brand owner or procurement contact to confirm intended use.
- Escalation notes: Send uncertain findings to counsel or the licensing contact before making a legal conclusion.
This section is informational, not legal advice. A practitioner should surface signals, preserve evidence, and hand disputed interpretations to qualified counsel. The website font licensing checklist can help structure that operational review.
Building a Repeatable Font Audit Workflow
A one-time inventory becomes stale after the next redesign. Make the process small enough to repeat and specific enough that design, engineering, and legal teams can divide ownership without arguing over definitions.
Assign each layer an owner
Engineering owns the Network review, loading behavior, payload, and fallback impact. Design or brand owns identity, approved families, and the relationship between live pages and campaign assets. Legal, procurement, or compliance owns license records, scope, renewals, and escalation.
Run the same sequence on representative templates:
- Inventory: Inspect
body, headings, navigation, forms, buttons, and distinctive components in DevTools. - Trace delivery: Filter Network requests by Font, capture files and sizes, and observe FOIT or FOUT.
- Crawl broadly: Use a scanner to find orphaned families, legacy declarations, and routes missed by manual sampling.
- Reconcile rights: Match every deployed face to a license ID, source, domain, and approved use.
- Record exceptions: Preserve screenshots, HAR files, PDF extraction output, image crops, and reviewer decisions.
Use a shared spreadsheet or database with columns for face name, PostScript name, style, source URL, license ID, approved domain, page locations, and bytes shipped. After every redesign, hold a short review while the implementation context is fresh. Run a deeper review on a recurring schedule, and flag any face whose license has expired or whose payload exceeds 80 KB per weight as an engineering and compliance review item.
A scheduled crawler or font-audit service can watch for new files, changed CSS, and unexpected families between manual reviews. Font Checker Pro scans live URLs, PDFs, images, and zipped font sets, then produces exportable reports for typography review, including font sources, performance signals, and licensing indicators. Use automation to detect change, but retain manual confirmation for rendered faces, uncertain image matches, and legal interpretation.
Practical rule: A font audit is complete only when the team can answer four questions: what rendered, what downloaded, what it cost the page, and what document authorizes its use.
Start with one production template today. Export the DevTools inventory, capture the font requests, attach the relevant license records, and give every unresolved face an owner and a deadline.
Font Checker Pro can scan live URLs, PDFs, images, and zipped font sets to create an exportable typography report that connects identification, payload, and licensing review. Visit Font Checker Pro to evaluate a repeatable workflow for your next handover, redesign, or compliance audit.
