JAB Code: a colour barcode format that ships as a C library

The symbology: one primary symbol and any number of secondary ones

JAB Code, for Just Another Bar Code, is a two dimensional matrix symbology whose basic symbols are made of colourful square modules arranged in either square or rectangle grids. The readme attributes its extra capacity to exactly that: it can encode more data than traditional black and white codes. The structure is more unusual than the capacity claim. A JAB Code contains one primary symbol and optionally multiple secondary symbols. The primary symbol carries four finder patterns located at the corners of the symbol, and the secondary symbol carries no finder pattern at all. A secondary symbol can be docked to a primary symbol, or to another already docked secondary symbol, in either the horizontal or the vertical direction. That docking is what lets a symbol grow beyond one grid, and it is also the part that makes reading harder, because a reader that has found a primary symbol has to work out which secondary symbols belong to it and how they are attached. The amount of data encoded correlates with the percentage of error correction the user specifies, so capacity is a dial rather than a fixed property.

Building the library, the writer and the reader

The build is old school and short. The core library, the reader application and the writer application are written in C, specifically C11, and were tested under Ubuntu 14.04 with gcc 4.8.4 and GNU Make 3.8.1. The core library builds first, in its own directory:

make

The writer and the reader are separate directories with their own makefiles, src/jabcodeWriter and src/jabcodeReader, and each is built the same way with make. The outputs are in documented locations: the built library lands in src/jabcode/build, and the two applications land in src/jabcodeReader/bin and src/jabcodeWriter/bin. Both programs document themselves, and the readme points you at the --help argument for jabcodeReader and jabcodeWriter rather than repeating the option list. The project also ships a demo web interface at jabcode.org, with a create page at jabcode.org/create, which is the fastest way to see what a symbol with a given error correction setting looks like before you write any code.

The Windows DLL path is the fiddly part

Building a DLL on Windows takes six steps and has one genuine trap. You start by downloading and installing mingw-w64. For 64-bit Windows the third step can be skipped, because the necessary libraries are already prebuilt. For 32-bit Windows you have to download the source of libpng, libtiff and zlib, build them as static libraries in mingw-64, and put the built libraries in the folder jabcode/lib/win64 to replace the 64-bit version. Then you rename the file Makefile.win to Makefile in the jabcode folder, run make in mingw-64 in that folder, and find the built DLL, libjabcode.dll, in jabcode/build. The trap is that the static libraries you build must match the target architecture, so the 32-bit and 64-bit paths are not interchangeable, and a mismatch shows up as a link failure rather than a runtime one. The image library trio is there because the reader and the writer have to handle PNG and TIFF input and output, and building them from source is what lets the DLL avoid depending on system copies of those libraries.

An ISO standard, an API document and a demo site

Three separate things are published alongside the code, and they answer three different questions. The technical specification of JAB Code is available as ISO/IEC 23634:2022, which means the symbology is not defined only by this repository, and a scanner built by someone else from the standard will read a symbol this library produced. That is the single most important fact on the page for anyone considering adoption, because it means the format is not a personal invention with a single implementation. The API documentation is available at jabcode.github.io/jabcode, which is where you go for the function signatures, the error handling and the encoding parameters. The demo web interface at jabcode.org/create is where you experiment, encoding a payload with a chosen error correction percentage and seeing the symbol. The repository structure supports the same split, with a docs directory and a src directory containing the three subdirectories for the library, the reader and the writer. An android_reader directory also sits at the top level of the tree, so a mobile reader is part of the project's thinking.

Where the project stands now

Two facts frame any decision to depend on this code. The first is that the repository publishes no GitHub releases, so there is no tagged version to install and no changelog of releases to read. You take the source, you build it, and you pin the commit you tested, which for a library that other people embed is a real operational cost because you own the build for every platform you support, including the Windows DLL with its three static libraries. The second is the maintenance signal, which comes from the last push on 2026-04-17. That is a quiet tree, and the readme itself does not claim otherwise. The licence is a custom file that GitHub cannot classify, so if you intend to ship a product with JAB Code inside it, read that file rather than trusting a badge. The technical specification being an ISO standard cuts both ways here: it means the format will outlive this implementation, and it means the specification is the thing to build against if you are writing a reader from scratch.

Editorial conclusion

JAB Code is the right choice if you have a use case where a black and white symbol is too small or too slow to scan, and you can control the printing and the reading device, because the format is designed around colour modules rather than around commodity scanners. It is the wrong choice if you need a format every phone camera can read, if you need an installable package, or if you need the project to still be moving. Before you build, read the ISO specification for the symbology details, plan the error correction percentage per symbol, and remember that the last push was on 2026-04-17 with no GitHub releases, so pin the commit you test.

Frequently asked questions

Official sources

1. Issues
2. jabcode/jabcode on GitHub
3. README