# fritzing-parts: the part library every Fritzing install pulls on startup > fritzing-parts is not an application but the data behind Fritzing, holding every shipped part definition as FZP metadata with its SVG artwork, split across a stable master branch and a develop branch where new parts and quality work land first. **fritzing/fritzing-parts** — Electronic components for use in the Fritzing app (aka the parts library) - Repository: https://github.com/fritzing/fritzing-parts - Website: http://fritzing.org/parts - Stars: 625 · Forks: 379 - Language: Python - License: NOASSERTION - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/fritzing-fritzing-parts ## Every Fritzing install already holds a clone of this The README explains the relationship in one sentence that changes how you read the repository. It contains all part definitions that are shipped with the Fritzing app, and every Fritzing installation contains a clone of this repository and is continuously updated through GitHub, so take great care when making changes. That is the whole design. Fritzing is a design tool for physical computing electronics, and the components you drag onto a breadboard canvas come from here. A part in this repository is not something a user downloads separately, it is something every user already has. That has an obvious consequence for contributors, which the README states as a warning rather than a rule, and it is why the branching model below exists. The audience is electronics hobbyists and educators who want a part to appear in the palette, and the licensing is a custom one that GitHub cannot classify, with the terms in LICENSE.txt. ## FZP metadata and SVG artwork travel together The data model is small and worth understanding. Parts are composed of meta-data in.fzp files and related graphics in.svg files, and the format is documented in the Fritzing wiki under the part file format. That pairing is the mechanism. The FZP file carries the metadata, which is the electrical and mechanical description of the component, its pin and connector definitions, its properties, and the links to the views. The SVG file carries the picture, and One part definition can reference several SVG assets, so the artwork side of a part is potentially more than a single picture. A contributor therefore never adds a single file. The README points to a tutorial on creating custom parts, and the wiki page carries the format details, so the actual definitions are a set of XML documents rather than images with captions. ## The develop branch is where new parts and fixes belong The branching model is explained directly, and it is the most important operational fact for anyone contributing. A master pull request results in a parts update for all Fritzing users, so there is a develop branch, and that branch is for new parts, testing and quality management. Pull requests should be committed to develop so that master stays clean and ready to use for everyone, and develop is merged from time to time once QA is done. In other words, master is production and develop is staging. The badge at the top of the README reflects this, showing a check-all-parts workflow badge for both master and develop. The default branch of the repository is develop, which is worth noticing, because cloning the repository gives you the staging branch rather than what most users actually run. ## fzp_checker.py validates FZP and SVG files The repository includes a checker script that validates FZP and SVG files for common issues, and the README says it can detect errors, provide warnings, and automatically fix many problems. The usage is direct. You point it at a single FZP or FZPZ file, at a directory to check everything in it, or use the SVG flag to check a specific SVG file, and the fix flag applies corrections where it can. ```bash # Check a single FZP or FZPZ file python fzp_checker.py path/to/part.fzp python fzp_checker.py path/to/part.fzpz # Check all parts in a directory python fzp_checker.py core/ # Check a specific SVG file python fzp_checker.py -s path/to/file.svg # Automatically fix detected errors python fzp_checker.py path/to/part.fzp --fix ``` The options are documented as a list: -c and --checks to select which checks run, by default all of them, -s and --svg to check an SVG file or to find the FZP files that use a given SVG, -f and --file to read a list of files to check from a file, -v and --verbose for verbose output, and --fix to correct errors automatically where possible. Two worked examples show the selective use. ```bash # Check specific types python fzp_checker.py mypart.fzp -c svg-dimensions svg-units # Find all FZP files that use a specific SVG python fzp_checker.py -s myfile.svg contrib/ ``` ## Where the parts live in the tree The top level entries describe how the library is organised. There is a core/ directory for the standard parts, a contrib/ directory for contributed parts, an svg/ directory for the artwork, a user/ directory, an obsolete/ directory for retired definitions, a bins/ directory, and a scripts/ directory. The FZP and SVG naming is not arbitrary, since an FZP file references its SVG assets by name and the two have to agree, which is why the checker script can take an SVG path and find the FZP files that use it. That single check is the one that catches the most common contribution error, where a part is added with artwork that does not match the filename the metadata expects. The obsolete/ directory also suggests a curation policy: parts do get retired when they no longer apply, and the same part folder structure and file format documentation governs the whole tree. ## Contributing a part, or sharing it in the forum The README offers two routes, and the choice between them is a matter of confidence rather than preference. The direct route is the contribution guidelines in CONTRIBUTING.md, which describe how to contribute a part straight to the repository. The alternative is to share the part in the Fritzing forum, and the README frames that as the option for people who find the direct contribution process too complex. That is a reasonable division, because a first-time contributor with an unusual component often benefits from a conversation before writing FZP by hand. The tutorial on creating custom parts is linked separately, and a part needs both the definition and the artwork, so the artwork is often where the work is. The forum route also keeps a part out of the shared library until someone with more experience has looked at it, which is the safer outcome for a first contribution. ## Where fritzing-parts is the wrong tool The limits are clear. This repository is the shared library, not a way to publish your own components privately, because a merged pull request updates the parts database for every Fritzing user, and the README's warning about taking great care reflects that. If you want a private part set for a course or an internal workshop, the answer is to keep that part local to your own installation, not to open a pull request here. Second, the scope is Fritzing's own format, so a part modelled in another tool's format has to be redrawn, and the FZP plus SVG pairing means the effort is split between data and artwork rather than being a one-file drop. Third, the release history shows the last tagged versions as 0.9.2b in June 2015 and 0.9.3b in June 2016, and although the repository is not archived and the last push was on 2026-08-12, the parts themselves move slowly compared with the application, which is a sensible ratio for a shared library. The alternative worth naming is the community parts forum route for individual components, and for private use a local custom parts folder, where the difference in approach is that nothing you draw has to pass a shared quality review before anyone else sees it. ## Conclusion Contribute to fritzing-parts if you want a component to appear in the Fritzing library for everyone, and if you can supply both the FZP metadata and the SVG artwork it references. Do not treat it as a way to ship your own private library, since a merged pull request updates the parts database for all Fritzing users. Verify first that your part does not already exist, that the SVG passes the dimensions and units checks in fzp_checker.py, and that you are targeting the develop branch rather than master, since a master merge ships immediately to every installation. ## FAQ ### What does the fritzing-parts repository contain? It contains all part definitions shipped with the Fritzing app. Parts are composed of meta-data in .fzp files and related graphics in .svg files, and every Fritzing installation contains a clone of the repository that is continuously updated through GitHub. ### Which branch should I submit a new part to? The develop branch, because a master pull request results in a parts update for all Fritzing users. The README says develop is for new parts, testing and quality management, and is merged from time to time once QA is done, keeping master clean and ready for users. ### How do I check a part file for errors before submitting it? The repository includes fzp_checker.py, which validates FZP and SVG files, reports errors and warnings, and can fix many problems automatically with the --fix flag. You can check one file, a whole directory such as core/, or a specific SVG with the -s flag, and the -c flag selects particular checks such as svg-dimensions and svg-units. ### Can I share a part without contributing to the repository? Yes. The README says that if the contribution process seems too complex, you can alternatively share your part in the Fritzing forum, and there is a separate tutorial on creating custom parts. ## Sources - [fritzing/fritzing-parts on GitHub](https://github.com/fritzing/fritzing-parts) - [Issues](https://github.com/fritzing/fritzing-parts/issues) - [Project website](http://fritzing.org/parts) - [README](https://github.com/fritzing/fritzing-parts/blob/develop/README.md) - [Releases](https://github.com/fritzing/fritzing-parts/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fritzing-fritzing-parts