Your web app, printing real paper.
Printol sits on the counter PC and turns a browser into something that can drive a thermal printer and an A4 tray directly. Your app sends an invoice object over loopback; a receipt comes out of the printer. No print dialog, no PDF download, no “please press Ctrl+P”.
Three lines in your web app
The SDK is one ES module with no dependencies. It discovers the bridge, handles pairing, and gives you a client. You never construct an ESC/POS byte, never pick a font, never count characters to make a column line up.
- → Works from any framework, or from none — it is a plain module off a URL.
- → Pairing is remembered, so the shopkeeper approves once and never again.
- → Prefer no SDK? It is a plain JSON API — every endpoint is documented.
import { connect } from 'https://printol.crawlink.com/sdk/printol.js';
// Finds the bridge on this machine, reuses a stored token, or asks the
// person at the counter to approve this browser once.
const printol = await connect({ appName: 'Anand Traders Billing' });
await printol.print({
templateId: 'pos.receipt.retail',
data: bill // your invoice object, not ESC/POS bytes
});How it actually works
Nothing leaves the machine. The web page talks to 127.0.0.1, the bridge talks to the printer, and the shop's data sits in a SQLite file under the user's
own profile directory.
- 1
Discover
Your page probes ports 47600–47619 in parallel and keeps whichever answers with the Printol marker.
- 2
Pair
The desktop app raises a dialog naming your site and showing six digits. Somebody at the counter clicks Allow. You get a token bound to your origin.
- 3
Send data
POST an invoice object and a template id. Not HTML, not bytes — the same payload prints on 58mm and on A4.
- 4
Paper
The bridge renders, spools and reports back. Poll the job, or subscribe to the event stream.
Why a desktop bridge at all
Because a browser cannot reach a printer, and the print dialog it offers instead is wrong for a counter: it is modal, it adds margins and headers, it cannot cut paper, and it certainly cannot kick a cash drawer.
A4 and 80mm from the same call
You send the bill. The bridge renders it for whatever paper the chosen printer is loaded with — a 32-column thermal roll, an 80mm roll, or a full GST invoice on A4 — and your code does not branch.
One payload. Four papers.
No print dialog, ever
The browser is not involved in printing. The bridge talks to the OS spooler, to a network printer on port 9100, or straight to a USB thermal head. Nothing pops up, nothing needs a click, nothing prints the page header on the receipt.
Silent by design, not by hack.
Discoverable on a port range
The bridge binds the first free port between 47600 and 47619. Your web app probes all twenty at once, keeps the one that answers, and remembers it. No configuration screen asking a shopkeeper for a port number.
Found in one round trip.
It is also a working till
Catalog with stock, invoices, payments, day-end totals and CSV export — usable on its own, on a counter with no internet at all. The API is a second way into the same local database, not a bolt-on.
Works with the web app, or without one.
10 templates, ready on install
Retail receipts, restaurant bills, kitchen tickets, token slips, shelf labels, GST invoices,
quotations, delivery challans. Each is a block tree you can copy and change — there is no
template language to learn beyond {{ }}.
The default counter receipt: items, tax summary, payment mode, QR.
Table, server, covers, and a service-charge line above tax.
Double-height items, no prices, one ticket per course.
One enormous number, and nothing else that matters.
Name, MRP, your price and a barcode, sized for a shelf edge.
Not just a bridge — a small till
A shop that has no web app yet can still use Printol on day one: build a catalog, track stock, raise an invoice, print it, and export the day's billing as CSV. When a web app does arrive, it reads and writes that same local database through the API, so nothing has to be migrated or entered twice.
Items, categories, units, tax rates, MRP and your rate. Import from CSV.
A ledger, not a number: every movement carries a reason and a reference.
Fast keyboard billing, split payments, held bills, reprint and duplicate.
System spooler, network 9100 or a file. A default per paper size.
Ten built-in layouts, editable, plus any your web app pushes in.
Day book, item-wise and payment-wise totals, and a CSV of the lot.
| Item | Qty | Amount |
|---|---|---|
| Masala Dosa | 2 | 180.00 |
| Filter Coffee | 3 | 120.00 |
| Curd Rice | 1 | 110.00 |
A local server, taken seriously
Software that opens a port on a shop's computer has to justify itself. Printol's answer is that the port is useless to anybody the shopkeeper has not personally approved.
Loopback only
The listener binds 127.0.0.1, not 0.0.0.0. Another machine on the shop wifi cannot reach it at all, and no firewall rule is needed.
A human approves each origin
Pairing shows your site name and origin on the counter screen with a six-digit code. No approval, no token. A page cannot pair itself.
Scoped, revocable tokens
A token is bound to the origin that asked for it and carries only the scopes granted. The shop can see every paired app and revoke any of them.
Free. Not free-for-now.
Every feature, every template, as many printers and as many paired web apps as you want. There is no paid tier waiting behind a wall, and nothing in the app will ever ask you for money or for card details.
No account
Nothing to sign up for. The app has no login screen, because it has nobody to log in to.
No licence key
Nothing to activate, nothing to lose, and no licence server that could ever switch a counter off.
No meter
Print ten bills a day or ten thousand. Nothing counts them, here or anywhere else.
Bundling it with your own software is free too, and needs no permission — the FAQ covers the details.
Install it, then print from this page
The playground runs the real SDK against the real bridge on your machine. If a receipt comes out of your printer there, your integration will work.