# jlcparts turns the JLC assembly catalogue into something you can query

> jlcparts is a static web catalogue for the JLC PCB SMT assembly parts library, with parametric search, sorting by any attribute and price at a given quantity, built by downloading the parts spreadsheet and generating per-category JSON that the browser queries in IndexedDB. It suits hobbyists and engineers who know the part they want but cannot find it in the vendor's own list.

**yaqwsx/jlcparts** — Better parametric search for components available for JLC PCB assembly

- Repository: https://github.com/yaqwsx/jlcparts
- Website: https://yaqwsx.github.io/jlcparts/
- Stars: 840 · Forks: 76
- Language: Python
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/yaqwsx-jlcparts

## A static page because there is no backend

The project is a better way to browse the components offered by the JLC PCB SMT Assembly Service, and the architecture is the reason it is easy to run. The page has no backend, so it can be hosted on GitHub Pages, and the hosted instance lives at yaqwsx.github.io/jlcparts. The stated reason for building it is a complaint about the vendor's own interface rather than about the parts. The README says the assembly service is easy to use, cheap and fast, and that the library itself is quite broad, but the library UI is the problem: you can only browse the categories, and you can do full-text search, with no parametric search and no sorting by property. The tool exists to add those two missing operations, plus price sorting by quantity and direct links to the datasheet and the LCSC product page.

## The pipeline from spreadsheet to JSON

The generation pipeline is described plainly in the README. Travis CI downloads the XLS spreadsheet from the JLC PCB page, a Python script processes it, and the result is a per-category JSON file with the components in it. The repository carries a `LCSC-API.md` file, which is the closest thing to a note about where the underlying data comes from, and a `jlcparts/` package with a `setup.py` that registers a console script named `jlcparts`, pointing at `jlcparts.ui:cli`, and depends on requests, click and lxml. The `web/` directory holds the frontend. The separation matters for anyone who wants to run their own instance, since the frontend is a static bundle of generated JSON and the Python side is the generator, and the two can be rebuilt independently.

## IndexedDB does the querying, in the browser

The frontend uses IndexedDB to store the component library and perform the queries on it, and that choice has a visible consequence for users. Before the first use you have to download the component library, and the README says it can take a while. After that, all the queries are performed locally. So the tool is a database client that happens to run in your browser, and the cost is paid once on the first visit rather than on every query. The upside is that a full-text search across a large catalogue, a parametric filter over several attributes and a sort by price at a given quantity all run against local data, with no server round trip, and the same reason a page with no backend can be hosted on GitHub Pages at all.

## The operations the vendor's own list is missing

The feature list is the argument of the project in six lines. You can do full-text search, browse categories, do parametric search, sort by any component attribute, sort by price based on quantity, and easily access the datasheet and the LCSC product page. Two of those are the reason to use the tool at all. Parametric search means you can filter the library by the electrical and physical properties a datasheet would list, which is how you find a part when you know the spec but not the catalogue number. Sorting by price based on quantity is the other, because assembly pricing scales with the number of distinct parts and with the volume, and the vendor's flat list does not show that. The screenshots in the README show a title page, a property filter and a component detail view, which is the shape of the workflow.

## Building the tables and running the frontend locally

Development needs NodeJS and Python 3, and the README splits the setup into the Python half and the frontend half. The Python side is installed into a virtual environment:

```bash
$ virtualenv venv
$ source venv/bin/activate
$ pip install -e .
```

You then download the cached parts database as shown in the GitHub Actions workflow, and process it into per-category JSON with the `jlcparts` command:

```bash
$ mkdir -p web/public/data/
$ jlcparts buildtables --jobs 0 --ignoreoldstock 30 cache.sqlite3 web/public/data
```

The frontend is then started from the `web` directory with npm:

```bash
$ cd web
$ npm install
$ npm start
```

The two flags in the build command are worth understanding. `--jobs 0` sets the parallelism of the table build, and `--ignoreoldstock 30` relates to stock, which is exactly the kind of field that goes stale between snapshot and use. The README also notes that the update job lives in a GitHub Actions workflow named `update_components.yaml`, which is where the spreadsheet fetch is defined.

## A focused scan instead of a full rebuild

The most useful thing in the development documentation is the test that lets you change one normalization rule without rebuilding the whole database. When you change an attribute normalization rule, you run the focused section scan:

```bash
$ PYTHONPATH=. pytest -q test/test_attribute_section_scan.py --attribute-section 'Peak Forward Surge Current'
```

If a `cache-v2.sqlite3` file is present in the repository root, that command reads raw values for only the selected section directly from the compact source database and does not rebuild the frontend datatables. You can pass `--attribute-section` several times to test a small batch, and `--attribute-value` to test raw values before rebuilding, as in the example that checks the Vbo range value 35V~45V. A different compact source database can be pointed at with `--attribute-source-db`, while the legacy `cache.sqlite3` format is still supported through `--attribute-sqlite` and is slower, because the raw attributes there are stored inside larger JSON blobs. Textual sections whose values contain no numbers need `--attribute-all-strings` with every generated string listed explicitly.

## MIT licensed, with a companion toolchain around it

The licence is MIT, and the project is published on GitHub Pages with the code in this repository, the `pytest.ini` at the root and the `test/` directory holding the unit tests. There are no GitHub releases, so the version to look at is the default branch, and the last push was on 2026-10-19. The repository is really the middle of a small toolchain by the same author, and the README points at the other two pieces. KiKit is a tool for automatic panelization of KiCAD PCBs that can also perform fully automatic export of manufacturing data for JLC PCB assembly, and it can produce a solder paste stencil for populating components missing at JLC PCB. PcbDraw makes schematic drawings of boards and population manuals. The author also asks for support through Ko-Fi to fund further hardware experiments. None of the three tools depends on the others at runtime, but if you use one of them, the other two are worth knowing.

## Conclusion

Adopt jlcparts when you already know the component family and the attributes you need and the vendor's own catalogue is the bottleneck, since the page adds parametric filtering, sorting by any attribute and price at a chosen quantity on top of the same parts list. Do not adopt it expecting live inventory, because the data is a generated snapshot that has to be downloaded before the first query and the page has no backend to refresh it. Verify first how current the snapshot is, since the update is a scheduled pipeline that downloads a spreadsheet and regenerates the tables, and note that the first visit has to pull the whole component library into the browser.

## FAQ

### What does jlcparts add over the JLC PCB parts catalogue?

It adds parametric search, sorting by any component attribute, sorting by price based on quantity, and direct links to the datasheet and the LCSC product page, on top of full-text search and category browsing.

### Does the jlcparts page need a server?

No. The page has no backend and is hosted on GitHub Pages. The component library is downloaded into IndexedDB in the browser on first use, and all queries then run locally.

### How do I build the component tables locally?

Install the Python package in a virtualenv with `pip install -e .`, download the cached parts database as the GitHub Actions workflow shows, then run `jlcparts buildtables --jobs 0 --ignoreoldstock 30 cache.sqlite3 web/public/data`, and start the frontend with `npm install` and `npm start` in the `web` directory.

### How do I test a single attribute normalization change without a full rebuild?

Run the focused section scan with `PYTHONPATH=. pytest -q test/test_attribute_section_scan.py` and an `--attribute-section` argument. With `cache-v2.sqlite3` in the repository root it reads raw values for that section only and does not rebuild the frontend datatables.

## Sources

- [Issues](https://github.com/yaqwsx/jlcparts/issues)
- [License: MIT](https://github.com/yaqwsx/jlcparts/blob/master/LICENSE)
- [Project website](https://yaqwsx.github.io/jlcparts/)
- [README](https://github.com/yaqwsx/jlcparts/blob/master/README.md)
- [yaqwsx/jlcparts on GitHub](https://github.com/yaqwsx/jlcparts)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/yaqwsx-jlcparts