picqer/php-barcode-generator for PHP 1D barcodes

Where picqer/php-barcode-generator fits in a PHP application

picqer/php-barcode-generator addresses a narrow but common server-side task: turning a supported text value into a linear, or 1D, barcode. It is intended for PHP applications that need barcodes embedded in a page, printed, saved as an image, or delivered through a document workflow. The package describes itself as framework independent and uses no Composer dependencies, so it can be introduced without selecting a particular PHP framework or adding a large rendering stack.

The documented standards include Code 128, UPC, and other 1D formats represented by the repository's type classes. A barcode type is more than a visual style. Each standard has rules about the characters it can encode and about the bar pattern used to represent them. Not every type accepts the same input, and the README warns that not every barcode scanner reads every type. Applications should therefore select the type from the scanning environment and data requirements rather than from the visual appearance alone.

The output is only the bar portion of the symbol. The package does not place the encoded value beneath the bars. That boundary matters for labels and receipts where people are expected to read a human-readable number. Adding text in the surrounding application is possible, but the README does not describe a built-in label layout, printer profile, quiet-zone configuration, or caption renderer. This is a barcode generation library rather than a complete label-design package.

Encoding and rendering inside picqer/php-barcode-generator

The library uses a two-stage data flow. First, a type class encodes a string into a `Barcode` object. Second, a renderer converts that object into a selected output format. This separation keeps encoding independent from presentation and allows the same encoded barcode to be sent to HTML, SVG, PNG, or JPG rendering.

For example, `TypeCode128` handles encoding while `HtmlRenderer` handles presentation. The HTML and SVG renderers accept fractional widths and heights because those formats can represent vector geometry precisely. The dynamic HTML renderer instead produces barcode markup based on its intrinsic dimensions so it can fit inside a fixed-size container.

Raster output follows a stricter sizing rule. For PNG and JPG, the final width should be an integer multiple of `$barcode->getWidth()`. The intrinsic barcode width represents the sum of its bar and space modules. Multiplying it by two makes every module two pixels wide. An arbitrary width can place module boundaries on fractional pixels, which may make bars visually uneven and can reduce scanner reliability. This is a concrete operational constraint for any server that generates PNG or JPG labels.

All renderers implement `RendererInterface` and expose the same main `render()` operation. Renderer-specific settings are applied through `set*()` methods for colors and related presentation choices. PNG and JPG can select between GD and Imagick when both extensions are installed. SVG changes between inline and standalone document forms through `setSvgType()`.

Installing picqer/php-barcode-generator with Composer

The README directs users to Composer for installation. This adds the package to an existing PHP application's dependencies and makes its autoloader available through the standard vendor directory.

composer require picqer/php-barcode-generator

After Composer completes, the application can load the package through `vendor/autoload.php`. SVG and HTML rendering require no additional image extension according to the README. PNG and JPG require GD or Imagick on the system. A deployment that only selects `SvgRenderer` or `HtmlRenderer` therefore avoids the extension requirement associated with raster output, while a PNG or JPG deployment must ensure that its PHP runtime has a supported imaging library.

The package has zero Composer dependencies, based on the README. That reduces dependency resolution and makes the installed footprint relatively small. It does not mean the generated image is available under every PHP deployment configuration. Renderer selection and required PHP extensions remain separate concerns.

Generating a first Code 128 barcode in PHP

The first example encodes `081231723897` as Code 128 and prints its bars as inline HTML. The type class creates the barcode data, and `HtmlRenderer` returns markup that the application can echo into a response.

<?php
require 'vendor/autoload.php';

$barcode = (new Picqer\Barcode\Types\TypeCode128())->getBarcode('081231723897');
$renderer = new Picqer\Barcode\Renderers\HtmlRenderer();
echo $renderer->render($barcode);

The rendered output contains the bars, not a caption showing `081231723897`. Applications that need a visible number must place that text in their own document structure. The README does not provide a complete HTML document example for this first use, so the relevant observable result is the renderer output rather than a claimed browser screenshot.

For a saved PNG, the same encoded object can be passed to `PngRenderer`. The width is calculated from the intrinsic barcode width so each barcode module occupies a whole number of pixels.

<?php
require 'vendor/autoload.php';

$colorRed = [255, 0, 0];
$barcode = (new Picqer\Barcode\Types\TypeCode128())->getBarcode('081231723897');
$renderer = new Picqer\Barcode\Renderers\PngRenderer();
$renderer->setForegroundColor($colorRed);

file_put_contents('barcode.png', $renderer->render($barcode, $barcode->getWidth() * 3, 50));

This writes `barcode.png` at three times the intrinsic width and a height of 50 pixels. The background remains transparent by default for PNG, according to the renderer documentation.

Choosing SVG, PNG, JPG, and HTML for barcode output

SVG is the clearest option when barcode geometry will be printed at different sizes. The README describes it as vector based and notes that it supports fractional output dimensions. It can emit either an inline SVG suitable for an HTML document or a standalone SVG image. Colors are supplied as three values from 0 to 255 for red, green, and blue.

$renderer = new Picqer\Barcode\Renderers\SvgRenderer();
$renderer->setForegroundColor([255, 0, 0]);
$renderer->setBackgroundColor([0, 0, 255]);
$renderer->setSvgType($renderer::TYPE_SVG_INLINE);
$renderer->render($barcode, 450.20, 75);

PNG and JPG are raster formats and require GD or Imagick. Both support foreground and background colors, plus `useGd()` and `useImagick()` when both libraries are available. The README gives PNG a transparent default background and JPG a white default background. Applications should select dimensions explicitly instead of accepting the default, because a default raster width may not be an integer multiple of the intrinsic barcode width.

`HtmlRenderer` emits bars as HTML for inclusion in a page and accepts float dimensions. `DynamicHtmlRenderer` uses the barcode's intrinsic width and height and is intended for placement inside a fixed-size container.

<div style="width: 400px; height: 75px"><?php echo $renderedBarcode; ?></div>

The formats share the encoding result but not their operational constraints. SVG and HTML avoid raster module quantization, while PNG and JPG require a server imaging extension and careful integer-width calculation.

Limits of picqer/php-barcode-generator for QR codes and labels

The first explicit limitation is 2D support. The README states that the package has no support for QR codes or other 2D barcodes. A QR code is not simply another renderer setting. It uses a two-dimensional matrix and a different encoding model, whereas this package creates the linear bars used by Code 128, Code 39, Code 93, EAN-13, GS1-128, MSI, UPC, and other supported 1D types.

The practical alternative for QR requirements is a QR-specific library or service that implements matrix encoding and its own image rendering. That approach is materially different from selecting another class here. The current repository does not provide such a mode, so applications cannot solve a QR requirement by switching from `PngRenderer` to `SvgRenderer`.

The second limitation is human-readable text. The package renders bars only. It does not provide the label text below the symbol, even though the encoded value is available to the calling application. This makes the package less complete for applications that require a finished retail label. The README suggests adding the text to the output later, but it does not document a ready-made caption or label template.

Scanner compatibility also cannot be inferred from successful image generation. Character rules differ among barcode types, and the README states that scanners do not all support all types. A generated file can therefore fail to match a workflow because of the selected standard, the raster width, or the target scanner rather than because of the renderer itself.

Maintenance, releases, and the LGPL-3.0 boundary

The repository is not archived. Its last push was on 2026-08-22, and the latest listed release is `v3.3.0`, dated 2026-08-22. Earlier listed releases include `v3.2.4` on 2026-01-08 and `v3.2.3` on 2025-07-29. These dates show recent repository activity, but the README does not describe a release cadence, support policy for older PHP versions, migration process, or long-term support window.

For maintenance planning, the Composer package boundary is simpler than a dependency-heavy library because the README states that it has zero Composer dependencies. Upgrade work still requires checking changes in the PHP package version, reviewing modified barcode type or renderer behavior, and running the application's own label and scanner checks. The repository includes `tests/`, `phpunit.xml`, `phpstan.neon.dist`, and generation scripts, but the README does not provide instructions for running them.

The package is licensed under `LGPL-3.0`. That identifies the repository's stated license, but this review does not interpret how the license applies to a particular application or distribution. An adopter must check the `LICENSE.md` and its own compliance requirements. The license is metadata relevant to adoption, not evidence about barcode compatibility or output quality.

Editorial conclusion

PHP applications that need dependency-light Code 128, EAN/UPC, or other supported 1D barcodes should evaluate this project, especially when SVG or inline HTML output is useful. Projects that need QR codes, generated caption text, or guaranteed compatibility with every scanner should look elsewhere. Before adoption, verify the required barcode type and characters, choose an integer module width for PNG or JPG, and confirm that the intended scanners read the resulting symbol.

Frequently asked questions

Official sources

1. Issues
2. License: LGPL-3.0
3. picqer/php-barcode-generator on GitHub
4. README
5. Releases