You're browsing a client's website when a heading catches your eye. The typeface has the right geometry, the apertures feel deliberate, and the spacing gives the brand a confidence your current project is missing. You take a screenshot, bookmark the page, promise yourself you'll identify it later, then lose the trail in a busy handoff.
The question, “what font is this website using?”, sounds simple, but a family name is only the beginning. A live page may declare one family while rendering another, load different files for different weights, combine hosted and self-hosted fonts, or use a fallback for characters the primary font doesn't support. Web fonts are now part of mainstream website infrastructure. The HTTP Archive's 2024 font data reports web fonts on around 87% of websites, with WOFF2 used by 81% of desktop websites and 78% of mobile websites.
A reliable audit therefore stacks several signals. You can inspect live CSS in DevTools, trace the actual font files through Network requests, use image matching when only a screenshot survives, and verify licensing before anyone adopts the typeface. The workflow below treats identification as the start of a defensible typography audit, not a trivia hunt.
Catching a Font You Want to Identify
The most useful font discoveries usually happen when you aren't looking for them. A designer is reviewing a client's homepage, selecting copy for a rebrand, or checking a competitor's landing page when a heading feels unusually well judged. Perhaps it's a geometric sans with tight apertures, or a humanist serif whose lowercase forms give long paragraphs an inviting rhythm.
The reflex is familiar: screenshot the heading, save the URL, and move on. That shortcut preserves the appearance but not the evidence. A screenshot won't tell you whether the browser loaded a variable font, whether the page uses a system fallback for accented characters, or whether the file comes from a licensed hosted service or an unknown upload.
Practical rule: Identify the rendered face first, then verify the file and its right to appear on the site.
Start with the live page whenever possible. Right-click the exact text, choose Inspect, and read the computed styles. This often gives you the family stack, weight, size, and line height quickly. If the result looks incomplete, open the Fonts panel and check which face the browser rendered. The page's Network panel then reveals the files behind that result.
When the page is unavailable, image matching becomes the fallback. Crop a distinctive word tightly, compare the leading candidates, and treat the result as a hypothesis. A visual match can narrow the field, but it can't prove which file a website delivered or whether a particular license covers web embedding.
The final path is a license pass. Record the exact family, file URL, weight, foundry, and license reference before the font reaches a production stylesheet. That sequence matters because the same typeface can have separate terms for desktop installation and browser delivery.
The methods complement one another. DevTools is fastest for a live page, Network inspection provides delivery evidence, image matching helps with archived or raster material, and license verification determines whether the candidate is usable. If one signal is ambiguous, the next method supplies the missing context.
Using Browser DevTools to Read the Font
DevTools usually answers the basic question in under a minute, provided you inspect the text that matters rather than the page as a whole.
Start with the rendered element
Right-click the heading or paragraph and select Inspect. In the Elements panel, keep the target node selected and open Computed. Search for:
- font-family, which shows the resolved stack inherited by the element
- font-size, which affects visual comparison and line wrapping
- line-height, which helps distinguish a deliberate type system from browser defaults
- font-weight, which identifies the requested weight or variable-font position
Computed styles reflect the cascade and inheritance. They don't necessarily show the rule that originally declared the value, and they don't prove that the first family in the stack supplied every glyph. A declaration such as font-family: Brand Sans, Arial, sans-serif can still render some characters from a fallback if the primary file lacks coverage or fails to load.
Open the Fonts panel
In Chromium-based browsers, select the element, open Styles, and use the font-family editor icon when it appears. The Fonts panel can show the rendered fonts for the selected text. This is the distinction that matters in a client audit:
- The family declaration is what the stylesheet requests.
- The rendered font is the face the browser uses.
- A fallback entry shows where the browser went when the preferred face couldn't supply a glyph.
Firefox provides a comparable view through its Fonts tab in the Inspector. Check more than one element. A site may use one face for navigation, another for headings, and a system stack for utility text.
Read the visual clues carefully
Small caps can expose a stylistic feature rather than a separate family. Variable fonts may expose axes such as weight, width, or optical sizing, so the visible result might not correspond to a standalone file named “Bold.” A browser can also display a fallback for one accented character while the rest of the word uses the intended face.
The Fonts panel workflow for listing fonts used on a page is especially useful when a page contains mixed typography or per-element overrides. For a broader tool-oriented workflow, the font finder guide for designers and developers offers another practical reference.
Rendered text beats a CSS guess. If the declaration and the browser's rendered-font list disagree, record both. The discrepancy is an audit finding, not an annoyance.
Inspecting Network Calls and @font-face Declarations
Computed styles tell you what the page asks for. The Network panel tells you what the browser downloaded.
Open DevTools, choose Network, enable the Font filter, then reload the page with the panel open. Look for requests ending in woff2, woff, ttf, or otf. WOFF2 is the dominant delivery format across current websites, which makes it the first place to look in a modern audit. The HTTP Archive font report also describes how web font use moved from near zero in 2011 to around 82% of desktop pages by 2020, about 84% by 2022, and around 87% by 2024.
Read each request as evidence
Click a font request and inspect the details:
- Status tells you whether the file loaded successfully or failed.
- Size helps identify whether the request is a full family, a subset, or a variable file.
- Timing shows when the browser requested it relative to page rendering.
- Initiator points to the stylesheet, script, or document that caused the request.
- Preview or response data may expose naming metadata, depending on the browser and file.
Reload with the cache disabled when you need to capture a clean request set. Test a heading, body paragraph, navigation label, and a string containing accented characters. A font that appears to work in the hero heading may not cover the full content system.
Find the @font-face rule
Use the Sources panel search for @font-face, or search the Styles pane for the family name. A typical rule includes a font-family label, a font-weight, a font-style, and a src descriptor such as:
src: url(...) format("woff2"), local("...");
The url() identifies a downloadable web file. A format() hint helps the browser choose among supplied formats. A local() reference allows the browser to use a matching installed face instead of downloading it, which can make two audits behave differently on two machines.
Hosted services often expose recognizable provider or foundry paths. Self-hosted files may sit under an assets, fonts, or static directory, while variable fonts can serve several weights through a single resource. Don't assume a readable filename is authoritative. Confirm the internal family and style metadata where possible.
Finish by recording the exact file URL, visible foundry or provider, loaded weights, styles, and any variable axes. The self-hosted web font guidance is useful when a site combines local files with a hosted stylesheet.
Identifying Fonts From Images and Screenshots
Image matching is the practical fallback when the live DOM is gone. It applies to archived pages, PDFs rendered as images, campaign graphics, posters, and server-generated headings where you can't inspect CSS or network traffic.
Begin with the crop, not the matching engine. Isolate one word or a short phrase, leave a small amount of whitespace around it, and avoid a dense paragraph with complex kerning. A tight crop gives the matcher cleaner glyph shapes. Image resolution helps, but crop quality often matters more because compression, antialiasing, and overlapping characters can distort the features used for comparison.
Build a useful candidate set
Use a distinctive word containing several informative letters. Lowercase a and g, uppercase R, and the numeral 1 can separate close cousins more effectively than repeated rounded letters. Compare the shape of terminals, aperture openings, serif brackets, and the relationship between thick and thin strokes.
Matching systems typically return a leading candidate and secondary possibilities. Treat the confidence score and the gap between candidates as decision support, not proof. If several families sit close together, the image doesn't contain enough distinctive evidence for a definitive answer.
A top visual match is a shortlist. The foundry specimen and the live file are the confirmation.
Confirm before adopting
Run a second crop using a different word from the same design. Then compare the candidate's glyphs at a similar size and weight. Helvetica-like sans faces, for example, can be difficult to distinguish from one another when the crop contains only common forms. The same problem appears among familiar humanist sans families.
The image font identification workflow provides a useful way to think about crop selection and candidate confidence. Once you have a likely family, find its specimen page and compare the exact characters, punctuation, numerals, and language coverage. Don't stop at a visual resemblance if the proposed font will become a brand asset.
An image can suggest the family, but it can't reveal whether the website loaded a licensed web file, a trial build, or a modified subset. Save the screenshot as supporting evidence, then verify the live implementation or source files through the other audit paths.
Choosing the Right Detection Method
Detection methods solve different problems. Pick based on the evidence you have, not on which technique sounds most advanced.
| Method | Best for | Accuracy | Skill required |
|---|---|---|---|
| DevTools | Live pages with accessible DOM and styles | High for the rendered element | Basic browser inspection |
Network and @font-face inspection |
Exact files, weights, sources, and delivery model | High for downloaded assets | Intermediate front-end knowledge |
| Image matching | Screenshots, PDFs, posters, and archived visuals | Probabilistic, dependent on crop and glyph clarity | Low to moderate |
| Automated page scanning | Repeated audits across URLs and assets | Broad coverage, dependent on scanner interpretation | Configuration and review |
DevTools wins on speed when the page is live and reachable. It fails as a complete answer when access is blocked, content is behind authentication, or the family declaration doesn't match the rendered fallback. Network inspection supplies stronger evidence about delivery, but it demands comfort with request initiators, caching, and CSS descriptors.
Image matching is available almost everywhere, yet it remains a visual estimate. It belongs later in a certainty-first audit unless the source is only a raster image. The manual versus automatic font scanner comparison helps frame that trade-off.
A hybrid workflow is usually fastest. Use the image to narrow candidates, DevTools to confirm the rendered face, and Network inspection to verify the exact URL, weight, and hosting setup. For recurring work across client sites, an automated scanner can create the inventory, while manual checks validate unusual or high-risk findings.
Verifying Licenses and Avoiding Costly Mistakes
Naming the family is the easy part. The expensive mistake happens when a team treats identification as permission to deploy.
A desktop font license generally covers local installation and uses such as design software, static images, logos, and PDFs. It doesn't automatically cover serving the font file to website visitors. Web embedding uses CSS @font-face, so it normally requires a separate web license. The web font licensing guidance explains that web terms are commonly structured around domains or monthly page-view tiers rather than the number of designer workstations.
The reverse error also appears. A team may download a trial or evaluation file, use it in a mockup, then ship that same asset to production without checking the permitted use. A font's availability in a public library or a familiar marketplace doesn't remove the need to read the applicable license, version, and usage limits.
Preserve an evidence packet
Capture licensing evidence at the moment you identify the font, while the page and files are still available. A useful packet includes:
- Page URL: Record the exact page and environment inspected.
- CSS evidence: Save the relevant
@font-faceblock and thesrcdescriptor. - Asset identity: Record the downloaded filename, internal naming data, and file hash.
- Observed date: Note when the asset was present and which weights or styles loaded.
- Rights reference: Store the foundry's license URL, purchase record, or contract reference.
- Scope notes: Document domains, traffic tiers, app or advertising use, and any restrictions that apply.
This trail helps a developer reproduce the finding and gives legal or compliance teams something concrete to review. It also protects against a common operational failure, where a font is approved for design work but nobody can prove that web embedding was included.
Understand the potential exposure
Using a desktop font on a website without the correct web license can lead to copyright disputes, back-licensing demands, and damages claims. One legal guide cites U.S. statutory damages of $750 to $30,000 per infringed work, with exposure rising to $150,000 per work for willful infringement. See the font licensing mistakes overview for that stated range and its legal context.
These figures don't determine the outcome of any particular dispute. Licensing obligations vary by foundry, usage, contract, and jurisdiction, so this article is informational and not legal advice. Have counsel review ambiguous terms, especially for enterprise deployments, agency handoffs, inherited websites, and assets acquired through third parties. The enterprise font compliance guidance also treats font licensing as a matter requiring careful legal and operational review.
For a practical audit loop, Font Checker Pro can scan live URLs, PDFs, images, or zipped font sets, identify typefaces and sources, flag unknown or potentially unlicensed files against an approved inventory, and export reports for legal, operations, or CI workflows. Use its output as an investigation aid, not as a substitute for the license document or legal review. The web font compliance guide is a useful starting point for organizing that process.
Recurring Audits and Quick Answers
A font audit shouldn't end when the first report is filed. Stylesheets change, agencies replace assets, licenses renew, and fallback behavior can shift after a browser or content update. Add typography to the same recurring review cycle used for other production dependencies.
Use a quarterly checklist
- Crawl scope: Verify which production pages, subdomains, PDFs, and asset repositories are included.
- Allowlist reconciliation: Confirm approved families and files match the live implementation.
- DevTools spot-checks: Inspect key headings, body copy, navigation, and multilingual text.
- License renewal: Record upcoming renewal dates, domain scope, and usage conditions.
- Fallback updates: Check that system stacks remain intentional and support the site's languages.
- Reporting: Compile findings, owners, evidence, and remediation actions for sign-off.
Fast answers for awkward cases
What happens with font-display: swap? The browser may show a fallback during loading and replace it once the web font arrives. Inspect after the page settles, then compare the rendered-font list with the initial visual state if layout shift or flash of unstyled text matters.
How do you identify a variable font? Look at the downloaded file and its @font-face declarations. A single resource may cover a range of weights or widths, while CSS exposes those values through font-weight, font-stretch, or variation settings.
Why does a locally installed font render when it isn't in the CSS? A local() source can let the browser use an installed face. Check the full src descriptor, then test in a clean environment to distinguish an intentional local source from a machine-specific result.
What's fastest for one glyph on mobile? Capture a tight screenshot of the glyph and a nearby character, crop aggressively, and compare candidates visually. A single letter rarely proves the family, so use the result to find a specimen for confirmation.
What if accented characters look wrong? Inspect a word containing the affected characters and check whether the browser reports a fallback. Font coverage, combining marks, rendering engines, and language settings can all affect the result.
Recurring detection turns what font is this website using into a maintainable control. Liability and implementation drift don't disappear after launch, so keep the evidence attached to the stylesheet and revisit it when assets or terms change.
Font Checker Pro can scan live pages and design assets, identify the fonts and sources in use, flag unknown files for review, and produce exportable audit records for design, engineering, and compliance teams. Visit Font Checker Pro to turn a one-time font identification into a repeatable audit workflow.
