The Label Printer Lies About DPI

An open-source Web Bluetooth driver shows that Niimbot’s N1 label printer, advertised as a 300 dpi device, actually prints at roughly 203 dpi.

The developer built the driver to print directly from a web page instead of using Niimbot’s mobile app. He reverse-engineered the proprietary protocol and exposed it to browsers via the Web Bluetooth API. In doing so, he discovered not just a missing feature but a fundamental mis-specification that can wreck small-batch packaging, inventory tags, or hobby projects where precision matters.

How the mis-specification surfaced

Niimbot markets the N1 as a 300 dpi printer, implying 300 dots per inch. The developer printed a ruler-scale image and a numbered test pattern, then measured the marks with a physical ruler. The math consistently pointed to about 203 dpi, not the claimed 300.

Four hard-earned lessons from writing a hardware driver

  1. A “successful” job may produce nothing. The printer streams data in bursts. On some platforms the Bluetooth stack drops a write without reporting an error. The driver assumes the job finished, yet the label comes out blank or truncated. The author now reads the printer’s physical page counter after each job to verify that a sheet was actually fed.

  2. Documentation is not reality. The 300 dpi claim is a clear example. Specs can be optimistic, outdated, or simply wrong. Developers must measure critical parameters themselves when visual fidelity matters.

  3. Physical marks beat “fit” tests. Printing an image to see if it fits the label area masks resolution, printhead width, or offset errors. Printing a known geometric mark and measuring its exact location reveals the device’s true behavior.

  4. A protocol describes grammar, not hardware temperament. Two printers may share the same command set yet behave differently—one handles rapid page repeats, another stalls. The driver cannot assume identical performance based solely on protocol docs; each model needs real-world testing.

Why the driver matters

The driver never pretends to know everything. Whenever it infers a value instead of reading it from the printer, it flags the field as a guess. This transparency stops silent errors that would otherwise consume hours of debugging.

Getting the driver

The driver runs in Chrome or Edge and needs only a Bluetooth-enabled device and a supported Niimbot printer. Try the live demo at:

https://iscarelli.github.io/niimbot-web-bluetooth/demo/

The source code lives on GitHub, where the community can contribute model data, fix bugs, or adapt the driver for other browsers:

https://github.com/iscarelli/niimbot-web-bluetooth

Niimbot owners can help populate the model database; the process takes about ten minutes and two labels.

Counterpoint

Until the company clarifies the discrepancy, developers must work with the measured value.

The takeaway is simple: hardware you call from a web page may not do what its spec sheet promises. Verify critical parameters, expect silent failures, and choose drivers that expose uncertainty instead of hiding it.