ESC/POS vs ePOS vs CloudPRNT vs StarPRNT

Four protocols move nearly every receipt printed today. ESC/POS is a raw byte stream pushed straight to the printer; Epson ePOS wraps printing in HTTP requests to an "intelligent" printer; Star CloudPRNT inverts the flow so the printer polls your server for jobs; StarPRNT is Star's own byte-level command language. They differ in who connects to whom, how fast a ticket lands, what status you can see, and — most expensively — which hardware you are then committed to buying.

The four at a glance

ESC/POS: the byte stream everyone forked

ESC/POS is not an API — it is the wire format. A job is a stream of printable text and escape sequences (1B 40 to initialize, 1D 56 00 to cut), delivered over whatever pipe exists: TCP port 9100, USB, RS-232, Bluetooth. The printer prints what arrives, in order, with no acknowledgment.

Architecture in words: your app opens a connection to the printer and pushes. There is no queue, no job object, no callback — flow control is TCP backpressure, and delivery confirmation does not exist unless you interleave DLE EOT status queries into the stream and parse the single-byte replies.

• Latency: the floor. Bytes hit the print head as fast as the LAN carries them — this is why front-of-house receipts on cloud POS systems still go point-to-point over the LAN.
• Status: possible but manual. 10 04 n queries return paper, cover, drawer, and error state in real time — when the printer bothers to implement them (byte-level guide).
• Lock-in: none in theory — everything from a $40 generic to a $500 Epson accepts ESC/POS. In practice every manufacturer forks the command set, so code tuned on one brand garbles on another. You escape hardware lock-in and inherit a QA matrix.

Full command detail, with bytes: ESC/POS commands: a practical reference.

Epson ePOS: HTTP to an intelligent printer

Epson's TM-Intelligent printers run an embedded web service. Your app — including JavaScript in a browser on the same LAN — POSTs an ePOS-Print XML document to the printer and gets a structured response back:

POST /cgi-bin/epos/service.cgi?devid=local_printer&timeout=10000 HTTP/1.1
Host: 192.168.1.87
Content-Type: text/xml; charset=utf-8
 
<epos-print xmlns="http://www.epson-pos.com/schemas/2011/03/epos-print">
  <text align="center" dw="true" dh="true">COFFEE CORNER&#10;</text>
  <cut type="feed"/>
</epos-print>

Architecture in words: still push, still LAN, but the endpoint is HTTP instead of a raw socket — which means browsers can print without agents, responses carry real success/failure and printer status, and no drivers exist anywhere. The printer is the print server. Some models add Server Direct Print, a poll mode where the printer fetches jobs from your server — Epson's answer to CloudPRNT.

• Latency: milliseconds; it is a local HTTP call.
• Status: the best of the four — every response reports success plus printer state, and the SDK exposes status events.
• Lock-in: total, by design. The SDK is free; the business model is that ePOS only exists on Epson intelligent hardware — a TM-m30III at $275–541 or an OmniLink TM-T88VII at $370–571, against $40–160 for a generic that prints the same receipt. Across a 3-printer store that is roughly $800–1,600 of name-brand hardware versus $200–350 generic. Software written against ePOS cannot drive anything cheaper, ever — that is the moat.

Star CloudPRNT: the printer polls your server

CloudPRNT flips the arrow. You do not connect to the printer at all; the printer makes an HTTPS request to a URL on your server every few seconds, asking whether a job is waiting:

POST /cloudprnt HTTP/1.1                        (printer → your server, every poll)
{ "printerMAC": "00:11:62:aa:bb:cc", "statusCode": "200 OK", ... }
 
HTTP/1.1 200 OK                                  (your reply)
{ "jobReady": true, "mediaTypes": ["application/vnd.star.starprnt"] }

The printer then issues a GET to fetch the job body, prints it, and confirms on the next poll. Newer CloudPRNT Next models add MQTT to cut the polling delay.

Architecture in words: pull, through the firewall, outbound-only. That is the genius and the cost in one move. Genius: an online-ordering platform can print into thousands of restaurants with zero inbound network configuration — the printer dials out. Cost: you must build and host a compliant server (Star publishes the protocol spec, you do the engineering), and every ticket waits for the next poll.

• Latency: seconds — the poll interval, plus fetch time. Fine for an online order landing in a kitchen; wrong for a card receipt a customer is standing there waiting for.
• Status: decent — each poll carries printer state, so your server learns of paper-out within a poll cycle.
• Lock-in: double. Star hardware only ($250+ models), and your printing now depends on your server being reachable: if the venue's uplink drops — or your endpoint does — printing stops. Star also sells StarIO.Online, a managed version of the server side, 90-day trial then a subscription with pricing available through sales.

StarPRNT: Star's answer to ESC/POS

StarPRNT is Star's native command language — same architectural shape as ESC/POS (raw bytes pushed over TCP, USB, or Bluetooth) with different byte values, plus polished StarIO SDKs for iOS, Android, and desktop. Many Star printers ship multi-emulation: they can run in StarPRNT mode (or the older Star Line Mode) or switch to an ESC/POS-compatible emulation — which is itself an admission of which dialect the industry actually writes.

• Latency and status: equivalent to ESC/POS — push over the LAN, with StarIO providing a cleaner status API than raw DLE EOT.
• Lock-in: the SDKs are good and free, and they drive only Star hardware. Code written against StarIO is code that cannot print to the Epson — or the $60 generic — your customer already owns.

Push vs poll: the architectural fork

Strip away the vendors and there are only two architectures on this page.

Push (ESC/POS, ePOS, StarPRNT): the app connects to the printer. Millisecond latency, works entirely on the LAN, survives any internet outage — but the app must be able to reach the printer, which is why push is the default for everything inside the building.

Poll (CloudPRNT, Server Direct Print): the printer connects out to a server. Traverses NAT with zero configuration, perfect for cloud-to-store printing — but adds seconds of latency and welds an internet dependency onto a device whose one job is to work during the dinner rush. The October 2025 AWS outage, which left Toast-dependent restaurants unable to operate for roughly 15 hours, is the failure mode in production.

The honest summary: poll architectures solve the vendor's connectivity problem by spending the operator's reliability budget.

When each one is right

• ESC/POS — you want hardware freedom and minimal moving parts, and you are willing to own status handling and per-brand quirks. The default for anything that must print offline.
• ePOS — an all-Epson fleet is already decided (or the budget is), you want browser printing without agents, and rich built-in status is worth $200–450 per lane.
• CloudPRNT — you are an online-ordering or delivery platform printing into stores you do not control, on Star hardware. Nothing else traverses those firewalls as cleanly. Accept the latency; keep a LAN path for anything time-critical.
• StarPRNT — a Star-standardized fleet where you want first-party SDKs on mobile, and the hardware commitment is acceptable.

A fifth shape: the protocol node

Notice what all four make you choose between: hardware freedom with byte-level pain (ESC/POS), or a good API with a hardware tax (everything else). The gap is a good API in front of any hardware — and that layer is what we build at ProxyNodes.

A ProxyNode is a ~$10 ESP32-based device beside the printer. Your software sees one HTTP/JSON API on the LAN (POST /print, GET /status, an SSE /events stream, mDNS discovery); the node speaks the printer's actual dialect on the other side. It also accepts raw ESC/POS on port 9100 with DLE EOT status replies, so a legacy POS drives it with zero integration — it just looks like a network printer. Push architecture, millisecond latency, nothing in the print path touching the internet. Swapping a Star for an Epson — or either for a generic — becomes configuration, not code.

You can exercise the whole API against the digital twin today — including fault injection for paper-out and offline, which none of the four vendor stacks lets you test in software. More for integrators at the developers hub, and the broader survey of printing approaches (drivers, relays, agents) is in the receipt printer API guide.