zint: a barcode encoder with seventy symbologies, and a licence that splits the library from the tools

Three deliverables hiding behind one project name

Zint is described as a suite of programs to allow easy encoding of data in the wide range of public domain barcode standards and to allow integration of that capability into your own programs. That sentence names two audiences, and the project structure follows it.

The first is the applications: a command line program and a graphical front end called Zint Barcode Studio. The second is the library, libzint, which is the C library you link into your own code. The repository layout keeps them apart, with a backend/ directory and a frontend/ directory, plus separate backend_qt/ and frontend_qt/ trees for the Qt based graphical version and a backend_tcl/ directory for another toolkit binding.

The library is what matters if you are integrating, because the applications are just convenient ways to use it. The README frames the whole project around the public domain standards, and the list of supported symbologies is long enough that the choice of an existing encoder is usually the difference between a week of work and a month.

There is also a packaging story around the applications: a debian/ directory, a win32/ directory, an zint.nsi file for the Windows installer, an zint.spec file for RPM packaging, and a zint-config.cmake.in template, which is what a project provides when it wants to be installed rather than merely built.

The symbology roster is long, and the long tail is postal

The README's format list is the clearest statement of what the library does, and it runs to more than seventy entries. The retail and industrial core is the familiar set: Code 128 with its GS1-128 and HIBC variants, Code 39, Code 93, Code 11, Code 49, Codabar, ITF-14, MSI Plessey, and the EAN and UPC family with EAN-2, EAN-5, EAN-8, EAN-13 and EAN-14, plus UPC-A and UPC-E.

Then there are the two dimensional formats, where a modern requirement usually lives: Data Matrix, QR Code, Micro QR Code, the rectangular rMQR variant, Aztec Code, Han Xin, PDF417, MicroPDF417, Codablock F, MaxiCode, Code 16K, and the GS1 Composite symbol.

And then the long tail, which is where a general purpose library earns its keep. The list includes Australian Post Redirect Code, Reply-Paid, Routing Code and Standard Customer, Brazilian Postal Code, Japanese Postal Barcode, Korean Postal Barcode, Dutch Post KIX, Deutsche Post Identcode and Leitcode, the Royal Mail 4-state and 2D Mailmark symbols, USPS Intelligent Mail (OneCode), UPU S10, and a set of specialised ones such as LOGMARS, Grid Matrix, Ultracode, UPNQR, Pharmacode One-Track and Two-Track, Pharma Zentralnummer, Telepen, VIN, and DX Film Edge Barcode.

That roster is the argument for the library rather than for any single format implementation. If your requirement is a postal code from a country nobody writes libraries for, or a GS1 composite symbol, you are otherwise implementing the symbology yourself, including the check digits and the quiet zones.

Output is an image file, in eight formats

The README is brief about output, and the list is short: output can be saved as BMP, EMF, EPS, GIF, PCX, PNG, SVG or TIF.

SVG and EMF are the interesting ones for a business application, because both are vector formats, so a symbol can be scaled for a label without resampling artefacts, and EMF is the format that the Windows printing stack handles natively. The raster formats cover the rest, with PNG the obvious default for anything on screen.

What the README does not spell out is the API shape, and that is a reasonable thing to look up in the manual rather than guess. The documentation is in docs/manual.txt and docs/manual.html in the repository, and online at the manual URL:

<https://zint.org.uk/manual/>

The manual is also where you would look for the per-symbology options, since the great majority of barcode work is not encoding the data but configuring the symbol correctly: module width, human readable text, quiet zone, and the various application identifiers that GS1 formats require. A project that exposes seventy symbologies must have a configuration surface to match, and the manual is the place to find it.

The project history is kept in a ChangeLog in the project root, which is the file to read when you need to know what changed in a given version rather than only what is present today.

The licence splits the library from the applications

This is the detail to read before you commit, because it changed and it is not uniform.

The README states that Zint, libzint and Zint Barcode Studio are Copyright (c) 2026 Robin Stuart, that all historical versions are distributed under the GNU General Public License version 3 or later, and that versions 2.5 and later are released under a dual licence. Under that dual arrangement the encoding library is released under the BSD 3 clause licence, whereas the graphical front end, Zint Barcode Studio, and the command line program are released under the GNU General Public License version 3 or later.

So there are two very different situations depending on what you take. If you link libzint into your own application, the BSD terms apply to that code. If you ship the command line program or the GUI, you are shipping GPL licensed software and the obligations come with it. The repository makes the split visible in its files as well, with a README.bsd sitting alongside README.linux, README.macos, README.windows and README.debian, and a separate LICENSE file.

The repository itself is classified with a custom licence category that GitHub cannot name, so the file in the tree is the authoritative text. Read LICENSE before redistributing anything, and this is not legal advice.

A related note appears in the support section, where the project asks people not to post messages asking for the licence arrangements to be changed, and says those messages will be ignored. That is a clear signal that the split is deliberate.

Where the code lives, and where to ask for help

The home of the project is its SourceForge page, and the code is mirrored on GitHub:

<https://sourceforge.net/p/zint/>
<https://github.com/zint/zint>

That arrangement is worth understanding, because it decides where your bug report should go. The README says feature requests and bug reports can be added as a ticket on the project's SourceForge page, or you can join the mailing list. The GitHub repository is the mirror, and the README does not present it as the primary tracker.

The support section is unusually specific about what is not supported and what is expected of a reporter. The project says it cannot provide support for using Zint with commercial packages such as MS Office or Crystal Reports, that you should always ensure you are using the latest version before posting a bug report because the bug may already be fixed, and that you should state your operating system and include enough information to reproduce the error, including input data where appropriate.

It also says the project is developed by volunteers, that it attempts to answer all messages within a week, and that this depends on external circumstances. That is the honest characterisation of a project maintained by one author with a mailing list, and it is the right thing to weigh if the barcode is on a production line and you need a guaranteed response time.

Where Zint is the wrong choice

The first wrong fit is a stack that cannot carry GPL terms. The library alone is fine under BSD, but if you need the command line program or the graphical front end, you are distributing GPL software, and the README is explicit that requests to change that arrangement will be ignored. A team with a policy against GPL in its dependencies has to take the library-only route, which means building the encoder into your own tooling rather than shipping the applications.

The second is a single, simple symbology with no GS1 or postal requirements. A dozen lines of encoder for a check digit and a table of bar widths is a real option when the format is Code 39 or Interleaved 2 of 5, and it avoids a dependency entirely.

The third is a workflow that needs the applications rather than the library. Zint Barcode Studio is there for a person generating a symbol by hand, and the command line program is there for a script. If your requirement is a human-facing tool, the library is the wrong half of the project to reach for.

The fourth is support expectations. With one author and volunteers, a week is an aspiration rather than a commitment, and the project does not support commercial packages at all. If an unanswered ticket means a stopped production line, that is an argument for a different arrangement, whatever the library's merits.

The fifth is the quiet one: a barcode that encodes the wrong thing is worse than no barcode, and the configuration surface for GS1 and composite symbols is where mistakes hide. The manual is the reference for those options, and the recommendation worth making here is specific: encode one of your real payloads with the settings you plan to ship and check it against a scanner before you build the rest of the flow on it.

Editorial conclusion

zint fits a team that has to emit a barcode in a specific symbology and would rather not implement the encoder, especially one that needs the GS1 flavours and the 2D postal formats that smaller libraries skip. It does not fit a project that cannot accept GPL terms anywhere in the stack, and it does not fit a case where you need the applications rather than the library. Before embedding it, decide whether you need libzint alone, because that choice is what keeps the BSD licence rather than the GPL.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. zint/zint on GitHub