# ngx-scanner: an Angular barcode and QR code scanner component
> The @zxing/ngx-scanner package gives an Angular application a camera barcode scanner as a single component tag, backed by the ZXing decoding library, with the version number tied to the Angular major it supports. It is easy to use and it is looking for maintainers, which is the thing to weigh before adopting it.
**zxing-js/ngx-scanner** — Angular QR code, Barcode, DataMatrix, scanner component using ZXing.
- Repository: https://github.com/zxing-js/ngx-scanner
- Website: https://zxing-js.github.io/ngx-scanner/
- Stars: 668 · Forks: 233
- Language: TypeScript
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/zxing-js-ngx-scanner
## One component tag is the whole integration
The package is `@zxing/ngx-scanner`, an Angular Barcode and QR-Code scanner component, and the repository description adds DataMatrix to the formats it handles. The decoding work is done by ZXing, the multi-format barcode library, which is what the project is named for.
The API surface is as small as it gets. The How To section of the README shows the entire usage, a single element in a component template:
```html
```
The README's own framing is that it is very easy to use, and for the basic case that is literally true: you add the tag, and the component talks to the camera and decodes what it sees.
What the short snippet does not show is the configuration surface, and that is where the real decisions live. The wiki is where the documentation lives, with a Getting Started page and a separate Performance Considerations page, and the README points at both. The performance page in particular is the one to read before shipping, because a camera decoder on a phone is doing a lot of work per frame and the tuning options are not self-evident from a component tag.
## The major version is the Angular major
The versioning policy is unusual and worth understanding before you pick a version.
The README states that the main version of @zxing/ngx-scanner will be compatible with the corresponding Angular version, and gives the example that @zxing/ngx-scanner@21.0.0 will be compatible with Angular 21. Then it adds an apology, in parentheses, for not using semver in the past, and a promise that future releases will use the same major as the supported Angular version.
In practice that means the package is versioned against the framework rather than against its own API. There is no compatibility matrix to consult, because the major tells you the Angular major. The trade is that you cannot take a patch release for a scanner bug without also moving to the Angular release it was built against, which for a team pinned to an Angular version is a scheduling matter rather than a technical one.
The recent releases follow that scheme exactly: v22.0.1 on 2026-07-02, and v22.0.0 and v21.0.0 both on 2026-06-29. Two majors published in the same afternoon, which is what a rebase onto a new Angular looks like in the release log.
## HTTPS in production is the one hard requirement
The Requisites section lists a single item, and it is not optional in practice: HTTPS for production environments, with a link explaining the underlying constraint.
That is the browser's secure context rule applied to camera access. A page served over plain HTTP cannot open the camera in a production context, so a scanner that works in a development environment on localhost can fail silently once it is deployed to a real domain over HTTP. The README puts it in the list of requisites rather than burying it in the wiki, which is the right place for the single most common reason a scanner component does not work after deployment.
Beyond that, the documentation is where the rest of the setup lives, with a Getting Started page linked from the README and a wiki described as the place for more information. The performance notes are linked separately, and the reason to treat that page as required reading is that a barcode scanner is a continuous decode loop over video frames, which is the kind of workload where a default configuration can cost a lot of battery and frame rate on a phone.
## Two demos, and both warn you about versions
The Demo section links two previews, the project's own site at zxing-js.github.io/ngx-scanner/ and a StackBlitz project, and it opens with a caveat that previews need to be opened in new standalone windows.
Then there is a second caveat, and it is the more useful one: some previews may not be fully updated, so check the version. That is a direct consequence of the versioning policy, where a live demo can be running an older build than the one you are about to install, and it is a reminder that the behaviour you click through in a demo is not necessarily the behaviour of the current release.
The standalone-window instruction is a separate point about how the component behaves. A scanner needs a real camera stream and a real rendering surface, and embedding it in a preview iframe or a page shell that constrains it produces a different result from running it in its own window. It is the same class of issue as the HTTPS requirement, where the environment rather than the code determines whether the feature works.
## Scanning and generating are separate packages
The README is careful to point at other projects for the other half of the job, and it does so in a way that clarifies the boundaries of this one.
For generating QR codes it points at ngx-kjua, and for writing QR codes yourself it points at the ZXing TypeScript port in the zxing-js/library repository. The scanner does not generate, and the generator does not scan.
That is worth pausing on, because the natural assumption for a package called zxing something is that it covers the whole barcode domain. It does not. What this project provides is the camera side: the component, the ZXing decoding in the browser, and the Angular bindings around them. If your application needs to print a QR code as well as read one, that is a second dependency, and the README names which ones.
The Angular binding is what the project actually adds over the ZXing library itself, and the same organisation maintains the TypeScript port, so the decoding layer is shared between them.
## The build runs a library project and a demo project
The package manifest shows two Angular projects side by side, and the scripts make that explicit:
```
"start": "ng serve zxing-scanner-demo",
"build": "ng build zxing-scanner --configuration production && cp README.md ./dist/zxing-scanner",
"build:demo": "ng build zxing-scanner-demo --configuration production",
"test": "ng test zxing-scanner --watch=false --browsers=ChromeHeadless && ng test zxing-scanner-demo --watch=false --browsers=ChromeHeadless",
"lint": "ng lint zxing-scanner && ng lint zxing-scanner-demo",
```
The pattern is worth noting for anyone who wants to reproduce a release. The library and the demo are built and linted and tested separately, and the test command runs both in headless Chrome, not in a jsdom environment, which is the right choice for a component that talks to a camera.
The rest of the scripts cover the documentation and the publishing path. There is a docs target that runs compodoc over the TypeScript configuration to produce API documentation into a docs directory, with build, serve and watch variants, a `build:gh-pages` target with a base href and an output path for the demo site, and a `publish:dist` target that changes into the built library directory and publishes it with public access. There is even a postinstall step that prints a message pointing at the project's Open Collective.
The repository root matches: an angular.json, a tsconfig.json, a tslint.json alongside an .eslintrc and a .prettierrc, a projects directory, a yarn.lock, a changelog.md, an ISSUE_TEMPLATE.md and a .travis.yml. One oddity worth flagging is that the package.json in the repository still carries version 1.0.0, which is clearly not the version that the release history and the npm badge refer to, so the manifest in the tree should not be trusted as the version indicator.
## The project is asking for a maintainer
The most important line in the README is the Attention note, and it is worth quoting in substance: while the maintainers do not have the time to actively maintain zxing-js anymore, they are open to new maintainers taking the lead.
That is an unusual thing to find at the top of a README, and it is a genuine factor in an adoption decision. The code is MIT licensed, the package is on npm, the wiki is written, the tests exist and the release history shows regular work, so the artefact is in good shape. What is missing is the person answering issues.
The financial side is handled in a way that is also worth noting. The README says financial contributions are welcome in full transparency on the Open Collective, that anyone can file an expense, and that if the expense makes sense for the development of the community it will be merged in the ledger by the core contributors and the person who filed the expense will be reimbursed. There are backers and sponsors listed, a Maintainer Wanted badge on the npm package, and issue templates for bug reports and feature requests on the repository.
The repository is not archived and the last push was on 2026-07-02, with v22.0.1 published the same day. So the code is current, and the open question is who maintains it from here, which for an adopter is a question about how quickly a regression in the camera handling would be addressed.
## Conclusion
ngx-scanner fits an Angular team that needs a QR or barcode scanner in the browser, wants the ZXing decoding library rather than a proprietary one, and is on an Angular version the package tracks. It is the wrong choice for a product that needs a long-term support commitment from the upstream project, since the README states plainly that the maintainers no longer have the time to maintain zxing-js and are open to new maintainers taking the lead. Verify first that the version you install matches your Angular major, that you can serve the application over HTTPS, and whether you would rather own a small wrapper component yourself.
## FAQ
### How do I use the ngx-scanner component in Angular?
You add the element to a component template, for example . The package is @zxing/ngx-scanner, and the README points at a Getting Started page in the project wiki for the configuration options.
### Which Angular version is a given ngx-scanner release compatible with?
The main version of the package is compatible with the corresponding Angular version, so @zxing/ngx-scanner@21.0.0 is compatible with Angular 21. The README notes that it did not use semver in the past and that future releases will use the same major as the supported Angular version.
### What do I need before the scanner works in production?
HTTPS for production environments is listed as the requirement, because camera access needs a secure context. The wiki also carries a Performance Considerations page, which matters for a component that decodes video frames continuously on a phone.
### Can ngx-scanner also generate QR codes?
No. The README points to ngx-kjua for generating QR codes and to the ZXing TypeScript port in the zxing-js/library repository for writing QR codes yourself. The scanner component covers reading.
### Is the ngx-scanner project still maintained?
The README carries an Attention note saying the maintainers do not have the time to actively maintain zxing-js anymore, while remaining open to new maintainers taking the lead. The repository is not archived, and v22.0.1 was published on 2026-07-02.
## Sources
- [License: MIT](https://github.com/zxing-js/ngx-scanner/blob/master/LICENSE)
- [Project website](https://zxing-js.github.io/ngx-scanner/)
- [README](https://github.com/zxing-js/ngx-scanner/blob/master/README.md)
- [Releases](https://github.com/zxing-js/ngx-scanner/releases)
- [zxing-js/ngx-scanner on GitHub](https://github.com/zxing-js/ngx-scanner)
---
Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/zxing-js-ngx-scanner