JLCPCB-KiCad-Library: symbols and footprints tied to one assembler's parts list

A library built around one assembly service

JLCPCB-KiCad-Library is a KiCad library of schematic symbols and PCB footprints with 3D STEP models attached, and its scope is deliberately narrow. The parts are drawn from JLCPCB's basic and preferred list, the catalogue of components the assembler already stocks without extra setup cost. The project description states the intent plainly, that the library is focused on those parts so no extra setup costs are incurred.

For the engineer who orders an assembled board, that focus is the whole point. A footprint that matches a supplier's part number means the BOM and the board agree, and the assembly line receives components it actually holds. A generic library gives you a footprint that is close enough for a datasheet, which is a different and weaker guarantee when the parts are going to be placed for you.

Two facts about the project's stance are worth keeping in mind. The author states that they are not affiliated with or sponsored by JLCPCB and are simply another customer, so nothing here is an endorsement or an official catalogue. The parts come from one assembler, and the library inherits that assembler's catalogue rather than the wider component market.

Stock and price are refreshed daily by GitHub Actions

The library's distinguishing feature is not the geometry but the commercial data attached to it. The feature list states that stock and pricing information is updated daily using GitHub Actions, and that every component carries a minimum order quantity and an attrition quantity. Datasheet links are included as well, and the price can be exported to the BOM.

The generation side of that pipeline is visible in the repository layout. There is a `libraryCreatorScript.py` alongside a `libraryCreatorScript.ipynb` notebook, plus `autoLibrarySymbols.py` for automatically produced symbol libraries and `handmadeLibrarySymbols.py` for the ones that were drawn by hand. Separate `packageTools.py` handles the packaging step, and a `metadata.json` file at the root carries the release metadata that the package manager consumes. The `resources/` directory holds the shared data, `symbols/` and `footprints/` hold the output, and `3dmodels/` holds the STEP files. There is also an `Archived-Symbols-Footprints/` directory, which is where retired parts are kept rather than deleted.

The published package format is what makes the daily refresh usable. The library is distributed as a KiCad package repository, so a symbol, its footprint, its 3D model and its price fields arrive together and stay in step with each other.

One repository file is an oddity worth mentioning: `LLM-Check-Pinswaps.ipynb`. The repository contains a notebook whose name suggests it checks pin assignments with a language model. Nothing in the documentation explains its role, so treat it as an experimental aid rather than a documented feature.

Attrition quantity is the field most order forms leave out

The library explains attrition quantity in its own documentation, and the explanation is the reason to care about this project. Attrition quantity is the number of parts wasted when setting up the machine, during adjustments or errors. When ordering parts you need either the minimum quantity the supplier allows, which is JLCPCB's minimum order quantity, or enough parts for the product plus extra to cover the ones wasted during setup.

The worked example is a good one to keep in mind. Building five boards that each need ten resistors means fifty resistors. If two parts are expected to be wasted during setup, the order is fifty-two, or the supplier minimum if that is higher.

This is exactly the sort of field that a symbol and footprint pair cannot express on its own, and it is where the cost of a build quietly appears. A library that stores the minimum order quantity and the attrition quantity per component turns a spreadsheet exercise into data that travels with the symbol, and it is the clearest example of what this project does that a generic library does not.

The compatibility claim also matters in practice. The project states support for Bouni's JLCPCB Tools Plugin, which is the plugin that reads this kind of component data inside KiCad, and compatibility with KiCad 8.0 and later, including 9.0.

Installing through the Plugin and Content Manager

The install route is the KiCad Plugin and Content Manager, which is also how the library stays current. You add the author's custom repository by pasting its URL into the manager:

https://raw.githubusercontent.com/CDFER/cd_fer-kicad-repository/main/repository.json

After saving, you pick CD_FER's KiCad repository from the dropdown, select the JLCPCB KiCad Library, click Install and apply the pending changes. The project also links an install guide video made by Rob Frohne for anyone who would rather watch the sequence than read it.

Updates are the rough edge. The documentation is candid that KiCad does not support fully automatic updates for this kind of package. KiCad notifies you that an update exists, and you then open the installed library manually, click update and apply the pending changes. The author calls it a bit annoying, and it is the main ongoing cost of using the library: a periodic manual step rather than a pull request.

The same message is the reason to keep the library in KiCad's own package manager rather than copying files into a project library. A copied footprint will never receive the daily price and stock refresh that the packaged version carries.

Editing the library means running libraryCreatorScript.py

The contribution path is documented step by step, which is unusual and useful for a library this size. You clone the repository to your own machine, install Python, set up a Python 3.13 virtual environment with the packages from `requirements.txt`, and then run `libraryCreatorScript.py`. The repository also contains a notebook version of the same script, and the instructions mention using the run button in the top right of the editor.

The dependency set is small and pinned. `requirements.txt` asks for `pandas==2.2.*` and `requests==2.32.*`, so the script fetches data over HTTP and assembles it with pandas. Formatting is handled by black with a line length of 120, configured in `pyproject.toml`:

[tool.black]
line-length = 120

Two warnings in the instructions are worth heeding. Do not commit changes to `metadata.json`, because release metadata is handled by GitHub Actions and a manual edit will be overwritten or will conflict. And avoid committing changes to the automatically generated symbol libraries, because editing the Python code instead of the generated output avoids merge conflicts for anyone else working in the same tree.

In other words, the generated artefacts are outputs, and the Python scripts are the source. Contributors are expected to change the scripts and let the pipeline rebuild the symbols.

Footprint correctness is still your responsibility

The author leaves a warning in the notes section that deserves to be quoted rather than paraphrased: even after testing the library on PCB orders, always check the output footprint and symbol. A library can be well maintained and still have a footprint that does not match the exact part you will receive, and the risk sits with the engineer who places the order.

Two coverage limits follow from the same place. The feature list says 99% of components include 3D models, which leaves a small share of parts without STEP geometry, and the 3D models are distributed as `.step` files so they open in SolidWorks and Fusion 360 as well as in KiCad's 3D viewer. Assembly drawings and mechanical checks that depend on the model will hit that missing tail.

The second limit is the catalogue itself. Because the scope is JLCPCB's basic and preferred list, a part that is not in that list is not in this library, and the `Archived-Symbols-Footprints/` directory shows that parts do leave the catalogue over time. If a component is discontinued or moved out of the preferred list, the footprint you have installed may no longer correspond to anything the assembler will stock. That is the moment to check the datasheet and, if needed, open an issue or a pull request so the entry can be fixed.

Compared with generic KiCad libraries and with the supplier's own data

There are two reasonable alternatives, and the difference between them is about where the data comes from. The first is the generic route: use the manufacturer's own KiCad libraries, or any symbol and footprint collection, and keep the ordering data in a separate BOM or spreadsheet. The geometry is equivalent in kind, and in many cases more trustworthy, since the manufacturer defines the package drawing. What you lose is the linkage: no supplier part number on the symbol, no stock or price field, no minimum order quantity, and no attrition quantity. The order planning work moves out of KiCad and into whatever you use for costing.

The second alternative is to keep the symbols generic and let a plugin fetch the commercial data from the supplier at design time. That is the approach behind Bouni's JLCPCB Tools Plugin, which this library explicitly supports rather than competes with. The trade is between a stored copy and a live lookup: the library carries a price that was correct when the package was refreshed, while a live lookup reflects the supplier's current state but requires a connection and a working plugin.

On the licence, the project is released under MIT with a copyright line naming Chris Dirks and the year 2024. The permissive terms mean you can use, modify and redistribute the library inside a design without a copyleft obligation, which matters for a commercial board because the symbols and footprints end up in files you share with customers and fabricators. That is a description of what the licence grants rather than advice on your obligations.

On maintenance, the repository is not archived and the last push was on 2026-09-21. The release tags are dated rather than numbered, with `2026.09.21`, `2026.08.08` and `2026.08.07` as the three most recent, so the tag name tells you exactly when a build of the library was produced.

Editorial conclusion

JLCPCB-KiCad-Library suits engineers who order assembled boards from JLCPCB and want footprints that match the exact part numbers on the assembly BOM, plus the stock, price and attrition fields that determine what a build actually costs. It does not suit a team that orders parts elsewhere, since the value of the library is the supplier specific metadata, and it does not replace checking a footprint against a datasheet, as the author asks. Verify the current version before trusting a footprint, since the release tags are dated rather than numbered, and check that the part you need carries a 3D model, because the project states that 99% of components include one.

Frequently asked questions

Official sources

1. CDFER/JLCPCB-Kicad-Library on GitHub
2. Issues
3. License: MIT
4. README
5. Releases