I have a generic Bluetooth thermal printer and need to print bills from my web-based SaaS. I could use the browser's normal print dialog, but I'm looking for a smoother option with better receipt formatting and support for features like paper cutting. I may also need to support USB, serial, network, and other printer types later. What architecture or tools would make this reliable across different printers?
4 Answers
QZ Tray is one option because it can send raw ESC/POS data from a browser to locally connected USB or serial printers. Check its current licensing and certificate requirements before committing, since signing and deployment may involve additional costs or setup. You could also build your own lightweight agent if you want complete control over updates, authentication, and supported printer protocols.
Starting with USB is sensible. Build the receipt-generation layer around ESC/POS, then connect it to a local agent through USB first. Once that works reliably, add Bluetooth and network printing behind the same interface. This lets you support the current MP-80M without designing the whole SaaS around one connection method.
For receipt printers, the browser print dialog usually becomes frustrating because of page margins, fonts, scaling, and the lack of reliable paper-cut commands. A better approach is to generate ESC/POS commands and keep receipt formatting separate from the code that sends those commands to a specific printer.
Would a tool such as QZ Tray work for the local-agent part, or would it be better to build a small bridge application ourselves?
A small local print agent is probably the most future-proof option. It runs on the customer’s computer, receives a receipt from the SaaS, and handles USB, Bluetooth, serial, or network printers locally. Your web app then uses one consistent API regardless of the printer connection. Libraries such as Node ESC/POS or python-escpos can help generate the command bytes, including barcodes, QR codes, code pages, and cutting.
Web Bluetooth and WebUSB can work in Chromium-based browsers, but they require permissions and often behave inconsistently with generic printers. Many inexpensive Bluetooth models also use unusual service or characteristic identifiers, so a local bridge usually causes fewer problems.
The printer I currently have is an MP-80M with USB and Bluetooth interfaces. Since USB is available, starting with USB support seems more practical than dealing with Bluetooth first. Does that sound like the right order?