Client sent over a Chinese font package downloaded from a font website and said to use it for headings—if we host it directly on the server, should we keep proof?

A client downloads a Chinese font from a font website and asks to use it directly for website headings. The risk usually is not the act of downloading, but where the font file ultimately goes and how it appears on the page. Based on typical delivery experience in 2026, writing only system font family names in CSS and letting the visitor's computer render them carries relatively low risk; once the font file is placed on a server and loaded externally via @font-face, or the font is used in a logo or banner image text, it usually falls within commercial licensing scope. The decision order should focus on usage method and documentation, not on whether the font looks good.

Web fonts follow two paths, and the risk levels differ

The first path is 'calling local fonts': write font-family in CSS and let the browser find installed fonts on the visitor's device. This path does not distribute the font file, and the actual appearance depends on the visitor's system; font weights and glyph shapes can differ on Mac, Windows, and mobile. The second path is 'embedding the font file': place the font file on the server and load it via @font-face so everyone sees the same glyphs. This path is equivalent to making the font file available for download externally and is usually treated as a usage act that requires a licensing basis.

Chinese web fonts also have a size constraint. A typical full Chinese font package is in the range of several MB, and loading it directly will noticeably slow the first screen. A common delivery practice is therefore to keep only one or two weights and subset the font based on the characters actually used on the page, compressing it to a few hundred KB. Subsetting then creates a new issue: when copy changes, characters missing from the subset fall back to system fonts, and two different glyph styles appear in the heading. In acceptance review, this often surfaces before the copyright issue does.

• Relatively low risk: write only system family names and do not load any external font files.
• Medium risk: load open-source commercially usable fonts, but check the license terms and retain required notices.
• Relatively high risk: load a 'free font package' from an unclear source, which may include commercial fonts.
• Easily overlooked: using the font in images, logos, or posters is design use and falls under a different licensing scope from web embedding.

Classify by usage into four tiers and first categorize the page

Treating font copyright as a broad yes-or-no question is not very useful; a more practical approach is to layer it by usage method. The same font appearing in a body-text fallback list and appearing in a logo involves completely different licensing scopes, and discussing them together only stalls both the client and the vendor.

1. Pure system font fallback: in font-family, write generic family names and common system fonts, without introducing files. One thing to note is inconsistent appearance across devices, which should be communicated to the client in the design notes in advance.
2. Self-hosting open-source commercially usable fonts: common with the Source Han series and some open-source font libraries. The key point is to check the original license text; some require retaining a copyright notice file, and some restrict the use of the font name. Do not go live merely because you 'heard it is free'.
3. Self-hosting or using a font service after licensing a commercial font: pay attention to the licensing scope, which is commonly defined by number of domains, page-view range, and whether modification is allowed. Obtain written authorization and keep it on file before purchase.
4. Using the font in a logo, banner image, or promotional material: this is design output and usually requires separate design-use authorization; web authorization does not automatically cover it.

Once the category is clear, the trade-off becomes clearer: what the client usually wants is a heading with a certain character, not one specific font. Restate the need as a character description, find close options in open-source font libraries, and in most cases within the experience range an agreement can be reached, while also saving the procurement and licensing cycle.

Delivery scene: no licensing fee in the budget, and the schedule is already set

A common project situation is: the client specifies a font, provides the asset themselves, the budget has no licensing fee, the launch date is already scheduled, and operations will later change heading copy. Our usual approach has three steps: first, ask the client to confirm the font source and licensing status in writing and put that statement into the design confirmation sheet; second, prepare a set of open-source alternatives for visual comparison and return the choice and corresponding risks to the client together; third, regardless of the path chosen, put the font file into the project repository, hand over the subsetting script and character list together, and hard-code fallback family names in the CSS.

The cost is one extra round of design revision in the early stage, with a typical range of half a day to two days. If this step is skipped, rework often happens after launch when a notice is received; at that point, changing the font also triggers a re-layout of the heading system, adding several days to about two weeks to the schedule, and you still have to explain why it was not raised earlier.

• Font packages from unclear sources: collections obtained from 'free font download sites' may include commercial fonts and are not recommended for direct use on public-facing sites.
• Design file and server mismatch: the designer's machine has the font installed, so it looks right, but the server does not have the file, and fallback is only discovered at launch.
• Missing characters after subsetting: only the characters in the launch copy were subsetted, so when operations change a heading, boxes appear.
• Text in images is forgotten: the web font was changed, but the line of text in the banner image is still in the old font, leaving two glyph styles side by side.

Self-hosted commercial fonts vs. open-source commercially usable fonts: a verifiable comparison

These two paths are not about good versus bad; they suit different stages. The ranges below are typical ranges in project delivery; actual terms depend on the vendor quote and project scale.

• Cost: open-source font licensing fees are close to zero; the main input is subsetting and debugging time, typically half a day to two days. Commercial fonts are billed annually or per site, with an experience range from several thousand to tens of thousands, varying by number of weights, number of domains, and whether modification is allowed.
• Timeline: open-source fonts can be implemented the same day; commercial fonts go through procurement and contract processes, typically requiring one to several weeks of lead time.
• Visual distinctiveness: commercial font glyphs are usually more distinctive and suit sites that require a unified external image; open-source fonts are widely used, so the chance of encountering a similar glyph shape is higher.
• Compliance management: with open-source fonts, someone must remember the license terms and retain notices; with commercial fonts, someone must monitor renewals and license expiry, and failure to renew on time is a common hidden risk.
• Size and performance: both require subsetting; untreated Chinese fonts will slow the first screen, so this item does not create a selection difference.

Applicable and non-applicable boundaries

Situations that justify careful font review: a public-facing official website, brand consistency requirements, heavy use of non-system fonts on pages, going global or multilingual sites, and later campaign materials. Once a font dispute arises on such a site, the impact covers the whole site, not just one page.

Cases that do not need to be escalated should also be stated clearly: purely internal management systems, intranet-only access, and sites with a controllable visitor scope can usually be handled with system fonts; pages that use only generic system family names and load no external font files do not involve font file distribution; and when body text uses system fonts, only a small amount of heading text is made into images, and design-use authorization has been confirmed, there is no need to purchase site-wide font licensing. The boundary can be remembered in one sentence: what matters is where the font file goes and where it ultimately appears, not what font name appears in the page.

Frequently asked questions

The client says this font was downloaded from a free font website. Should we still check?

Yes. 'Free' usually means free for personal, non-commercial use, while commercial use requires separate authorization. Ask the client to provide the original license text or a licensing statement and keep it with the project file.

If the font is only used in a logo image and the webpage does not load the font file, does it still count as use?

Yes. Use in an image is design use and falls under a different licensing scope from web embedding. You need to separately confirm whether the license covers design output.

If we only discover after launch that the font source is unclear, should we change the font first or take the page down first?

First stop using the font file and fall back to system fonts so the page still opens normally, then carry out replacement and minor layout adjustments. Usually the whole site does not need to go offline.

After switching to an open-source font, the client thinks it does not look as good as the original. How should we discuss it?

Restate the need as a character description and prepare comparison drafts with two or three close open-source fonts. Most clients judge overall look and feel, and within the typical range it can be settled in one or two rounds.

In practice, it is advisable to include font source confirmation in the design finalization step rather than filling it in just before launch. Whenever non-system fonts are involved, keep a record of the source and authorization at delivery and prepare open-source alternatives as backup. If the site is intranet-only or uses only system font family names throughout, there is no need to purchase additional licensing for this purpose. Whether a specific case constitutes infringement should be based on the font vendor's license agreement and necessary legal advice.