jaywcjlove/free-font: A Commercial-Use Font Catalogue Built From a Script Directory

The problem free-font addresses: a shortlist, not a licence

Finding a typeface is easy. Finding one you are allowed to ship in a commercial product, in both Latin and Chinese coverage, is the part that stalls a project. free-font is a curated collection of free English and Chinese fonts that the project describes as usable for commercial purposes. The README states the scope in one line: a collection of free fonts for commercial use, with Chinese coverage called out in the repository description.

The audience is narrow and practical. A designer or front-end engineer building a bilingual product needs a Chinese face with a usable Latin companion, and needs to know the licence before it reaches a build. free-font answers the first question with a browsable catalogue and the second with per-font notes. It does not answer licensing on your behalf. The repository is MIT licensed, but that MIT licence covers the project's own code and templates, not the fonts it lists. Each font carries its own terms, and the catalogue is a pointer to those terms, not a substitute for them.

How the catalogue is generated: scripts, fontkit, and an EJS build

This is not a hand-maintained Markdown list. package.json shows a Node pipeline with a build step. The scripts directory holds main.mjs, which the npm scripts invoke, and rename-images.mjs for asset housekeeping. Font metadata is read with fontkit, sizes are formatted with pretty-bytes, and Chinese names are handled with the pinyin package. Puppeteer is a devDependency, which points at browser-driven work in the pipeline, most likely rendering previews or capturing pages.

The rendered site comes from templates/ through @wcj/ejs-cli, with the output written to docs/. That output directory is what gets published, and it is also what the Dockerfile copies. The npm scripts split the work: npm run all runs the metadata script and then the build, npm run start renders templates once, and npm run dev renders with a watch flag. There are also narrower entry points, one:info and one:info:all, that drive main.mjs in an information-only mode.

The architecture is a static site generator with a data-collection front end. Nothing runs at request time. That is a deliberate constraint: it keeps hosting cheap and the page fast, and it means the catalogue is only as current as the last build. If you fork it to add fonts, you are editing templates and re-running a Node script, not filling in a CMS.

Installing free-font locally and rendering the catalogue

The package.json declares engines.node as >=20, so start there. Clone the repository and install dependencies. The project uses npm scripts throughout; there is no published npm package to install, since the package is marked private: false but ships no library entry point.

node --version
git clone https://github.com/jaywcjlove/free-font.git
cd free-font
npm install

The clone gives you the scripts, templates and docs directories. After npm install, the quickest way to see the site is the one-shot build, which renders every template in templates/ into docs/.

npm run start

Open the generated file in docs/ in a browser. If you are iterating on templates or data, use the watch variant instead, which re-renders on change.

npm run dev

The full pipeline, which runs the metadata script first and then the build, is the heavy command. It is invoked with an increased heap and garbage collection exposed, which tells you the font scanning step is memory-hungry.

npm run all

If you would rather not install Node at all, the repository ships a Dockerfile based on lipanski/docker-static-website. It copies ./docs into the image, so it serves the already-built site and does not run the generator. Build it only after docs/ exists.

docker build -t free-font .
docker run --rm -p 8080:80 free-font

The image serves the static output; the .dockerignore file controls what ends up inside it, as the Dockerfile comment notes. There is also a build:docker script that passes a global docker flag to the EJS CLI, which suggests the templates branch on that flag when rendering for the container.

Where free-font stops being the right tool

The catalogue is a reference, and the gap between a reference and a working font setup is where projects get hurt. free-font does not subset fonts, does not convert them to WOFF2, and does not generate @font-face rules. For Chinese faces this matters more than for Latin ones, because a full CJK font can be several megabytes. Nothing in the repository addresses that; you take the file and solve the weight problem yourself.

The licence notes are the second gap. The project labels fonts as free for commercial use, but the licence field in package.json (MIT) applies to the repository, and the README does not state a verification process for the fonts themselves. A catalogue entry is a claim, not a warranty. If your legal exposure is real, the catalogue narrows your search and then you confirm at the upstream source.

Maintenance is also worth reading carefully before you depend on it. The last push to the default branch was on 2026-08-04, and releases v2.28.0 and v2.29.0 landed the same day. That is recent activity, but the release cadence is uneven: v2.27.0 was on 2026-05-11, roughly three months earlier. The project is not archived. It is also a personal collection maintained by one author, with the README dominated by sponsorship and app-promotion blocks, so treat the update rhythm as best-effort rather than a service level.

How free-font differs from Google Fonts and font managers

The obvious alternative is Google Fonts, and the difference in approach is structural. Google Fonts is a hosted delivery service: it serves font files from its own CDN, generates the CSS for you, and covers a large Latin catalogue with a growing set of CJK families. free-font is the opposite. It is a static, self-hosted catalogue whose output is a directory of files you download and ship yourself. If you want a script tag and nothing else, free-font is the wrong shape.

The second alternative is a desktop font manager such as FontBase or a local font library in your operating system. Those solve activation and previewing on your machine. free-font solves discovery and provenance: it collects English and Chinese faces in one place with a commercial-use label attached. A font manager will not tell you whether a face is licensed for embedding in a product; free-font at least attempts to.

The third comparison is to a generic free-font aggregator site. Aggregators optimise for volume and download conversion. free-font optimises for a maintainable repository: the data lives in scripts and templates, the site is generated, and the whole thing is MIT licensed and forkable. That is a meaningful difference if you want to audit or extend the list rather than just download from it.

Licence implications and what upgrading actually costs

The repository's own licence is MIT, which is permissive and places few obligations on you if you fork the code, templates or scripts. The fonts are a separate question entirely. The project describes them as free for commercial use, and that description is the project's claim about each font, not a grant the project can make. MIT on the repository does not extend to the font binaries it points at. If you embed a font in a product, the font's own licence governs, and some free-for-commercial fonts still restrict redistribution of the font file itself even when they permit use in a design.

Upgrade cost is low in the code and non-trivial in the content. Because the site is generated from scripts and templates, pulling a newer version means re-running the pipeline and re-checking your shortlist, since entries can change between releases. Node >=20 is the only runtime requirement stated. The Docker path is even cheaper: the image is a static file server over docs/, so an upgrade is a rebuild once the new docs/ is generated. The real cost is review time. Every release can add, remove or relabel fonts, and a relabelled licence is the kind of change that should trigger a look at the upstream source rather than a silent rebuild.

Editorial conclusion

Adopt free-font if you need a starting shortlist of English and Chinese typefaces that the project already labels as commercial-use, and you are willing to confirm each licence at its own source before shipping. Skip it if you need a font manager, a webfont CDN, or a legally authoritative licence database: the repository ships a Dockerfile for a static site and a Node script pipeline, nothing that resolves licensing for you. Before you rely on it, check the per-font entry for the licence note you need, verify the last push date against the fonts you plan to embed, and confirm that the font file you download is the same one the catalogue entry describes.

Frequently asked questions

Official sources

1. jaywcjlove/free-font on GitHub
2. License: MIT
3. Project website
4. README
5. Releases