Chinese Free Web Font Storage: A Cut-Up Font Library for Full-Page CJK Coverage

The problem is file size, not font choice

CJK fonts are large because the character set is large. The README states the constraint directly: on the web, the number of Chinese fonts that can be supported and used is very limited because of the sheer size of the Chinese character set. A single unsubsetted CJK font file is not something you can hand a browser on a normal page load. That is the problem this repository exists to solve, and the README frames the goal as making full-site, full-text font coverage possible for any site.

The audience follows from that. The README splits it in two: developers view fonts on the official site, get web support, and reference a CSS file; designers who need the original font file click the GitHub icon to download it. So the project serves people who want to use a font in a page and people who want to install the font on a machine. It does not serve people who want to draw or modify glyphs. There is no editor here.

cn-font-split does the chunking, Imagekit.io does the serving

The mechanism is a font splitting step, not a runtime loader. The README credits cn-font-split as the deployment scheme and notes that it has been part of the project since the beginning. Chunking a CJK font means the browser fetches only the pieces it needs for the characters on the page instead of the whole file. The README does not spell out the chunking strategy, the number of chunks, or the unicode-range logic in the pages available here, so treat the exact splitting behaviour as something to confirm from the cn-font-split repository rather than from this one.

Delivery is the second half. The README states that Imagekit.io provides the static file solution and that the project's fonts are deployed on Imagekit.io. That is a real architectural commitment: the CSS you reference points at a third-party host, not at your own server. The README also says the project hopes for a public-interest CDN that can keep offering free font service the way Google Fonts does, which reads as an acknowledgement that the current arrangement is not that.

The repository itself is the source of truth for font files. The README instructs contributors to place font source files under the packages folder, after which the project automatically packages and groups them. The npm packages are published separately, and the README lists three related tools: the cn-font-split plugin, vite-plugin-font (which the README says supports Vite, Next, Nuxt and Webpack), and font-now, a font CDN service where users upload their own fonts.

Getting a font onto a page, and getting a font into the repo

For consumption, the README points at the official site. You browse the fonts there, get web support, and reference a CSS file directly. The README names result.css as the file you import, and it carries one warning about it: assigning two fonts on the same DOM element when using result.css may cause an error. That is a concrete constraint on how you compose font stacks, and it is the kind of thing that shows up as a silent rendering bug rather than a console error.

For contribution, the README requires Node 18 or above. The flow is: prepare the font link and licence information, fork the project, then run npm i to install, then npm run new dyh, where dyh is described as the first English combination of the pinyin of the font's Chinese name. That command creates a dyh folder from a template inside packages. You then drop your font file into packages/dyh/fonts and try a build with pnpm build --single=dyh. Note the mix of package managers in the documented commands: npm for install and scaffolding, pnpm for the build. If you only have one of the two installed, the flow as written will not complete.

Submissions also work without a pull request. The README says you can open an issue with the font link and licence information. The project states it only accepts fonts that are free for commercial use, and pull requests go through human review before the font is uploaded. The README points to a Developer.md file for the upload and deployment procedure, so the deployment steps are not in the main README.

The CDN is the dependency you are actually taking on

The most consequential limitation is not technical, it is operational. Fonts are served from Imagekit.io, and the README's own wish for a public-interest CDN suggests the project does not consider this settled. If you reference result.css in production, your page's typography depends on a host you do not control and on a project that has no stated availability guarantee. The README gives no SLA, no fallback origin, and no self-hosting instructions for the published CSS. You can still self-host the underlying font files if the licence allows it, but the README does not document that path.

There is a second gap that matters for anyone evaluating coverage: the README warns that some Chinese fonts have no English portion, and suggests combining with Google Fonts when you need Latin glyphs. So a font from this library may not cover the Latin text in your UI, and you will be mixing sources to get a complete page. That interacts badly with the result.css warning about two fonts on one DOM node, because the natural fix for missing Latin coverage is exactly to stack a second font.

Finally, the licence situation is per-font, not per-repository. The repository is MIT, but the README is explicit that you should respect the rights of the type designers and notes that the font file header information was exported into the font detail pages so you can review author and licence data. MIT on the repository does not make the fonts MIT. Nothing here is legal advice; the point is that the licence you must check is attached to each font, and the project has given you a place to read it.

How this differs from Google Fonts and from self-hosting

Google Fonts is the obvious comparison, and the README makes it itself, both as an aspiration for a public-interest CDN and as a practical workaround: the project embeds Google Fonts query functionality in its own site so people in regions without good access to Google Fonts can look up CSS links. It pulls the data and files from FontSource's npm static repository, which the README credits. So the relationship is not purely competitive. The difference in approach is that Google Fonts is the origin and the infrastructure; this project is a catalogue plus a chunking pipeline, and it leans on other parties for hosting and for the Google Fonts data it displays.

Self-hosting is the other alternative, and it is the honest one for teams with strict performance or availability requirements. If you run cn-font-split yourself and serve the chunks from your own origin or CDN, you get control over caching, over the host, and over which fonts are available without waiting for review. What you give up is the convenience of a maintained catalogue and a CSS link you can paste. The trade is roughly: this project optimises for time-to-first-font, self-hosting optimises for control. The README does not present these as competing options; it presents the project as the way to get web support quickly.

Maintenance cost sits with the maintainers, not with you

For a consumer, the maintenance burden is close to zero: you reference a CSS file and the project rebuilds and redeploys. The README links a Netlify deploy status badge for the chinese-font site, which tells you deployment is automated through Netlify. There are no retrieved releases in the material provided, so there is no version history to reason about here, and you should not infer a release cadence from anything in this article.

For a contributor, the cost is the review queue. Pull requests are manually reviewed and then uploaded, so a font you add does not appear on the site until a human processes it. If your project needs a specific font that is not in the catalogue, you are waiting on someone else's schedule, and the README offers no timeline. The npm side is separate: the README says the project has been published to npm and welcomes developers to use it, and it links vite-plugin-font on npm, which is the piece that matters if you are building with a bundler rather than pasting a link.

On licensing, the repository carries MIT. The fonts do not. Each font's author and licence data is exported into its detail page, and the project accepts only fonts that are free for commercial use, which is a filter applied at submission time by human review rather than an automated check you can inspect.

Who this is for, and what to check before you commit

Use it if you are building a Chinese-language site, you want a free commercial-use webfont, and you would rather paste a CSS link than run a splitting pipeline. The chunking is handled for you, and the catalogue plus detail pages give you the licence information in the place you need it. The vite-plugin-font package is the path to take if your build is Vite, Next, Nuxt or Webpack, since it is the project's own bundler integration and it is published to npm.

Do not use it if your font is not free for commercial use, if you need a font that is not in the catalogue and cannot wait for manual review, or if depending on Imagekit.io for typography is unacceptable for your availability requirements. In that last case, run cn-font-split yourself and serve the output from your own host.

Before shipping, do three things. Open the font's detail page and read the exported header data for author and licence, because the repository's MIT licence does not cover the font files. Load result.css and check the actual glyph coverage of your page, since the README warns that some CJK fonts have no Latin portion and you may need Google Fonts alongside. And test your font stacks on a single DOM element, because the README states that assigning two fonts on the same element with result.css can produce an error.

Editorial conclusion

Adopt it if you need free commercial-use CJK webfonts and want a CSS link rather than a self-hosted build pipeline, and if you accept that the files are served from Imagekit.io rather than from your own origin. Do not adopt it if your font is not free for commercial use, if you need a font that is not in the repository and cannot wait for human review, or if you need a guarantee about CDN availability that this project does not offer. Before you ship, open a font's detail page and read the exported header data for the author and licence, then load result.css in a browser and confirm the glyphs you actually need are present, because the README warns that some CJK fonts carry no Latin coverage.

Official sources

1. Issues
2. KonghaYao/chinese-free-web-font-storage on GitHub
3. License: MIT
4. Project website
5. README