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 an HTTP client rather than a driver stack does the talking, responses carry real success/failure and printer status, and no drivers exist anywhere. Epson's SDK overview documents browser printing on supported models. We have not qualified current browser permissions, CORS or certificate behavior. 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 can never drive the $40 generic — that is the moat. We compare the escape routes in Epson ePOS alternatives.

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 in the HTTP poll mode every ticket waits for the next poll. CloudPRNT Next models add MQTT, which does not work that way; which mode a given printer and server run is Star's to state and we have not measured either.

• Latency: in the poll mode, 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. The MQTT method is a different profile and is not characterised here.
• 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: a cloud endpoint needs the uplink, while a local server depends on the LAN. Star also sells StarIO.Online, a managed version of the server side, with a 90-day trial; confirm regional paid terms with Star (Japan FAQ). The push-based counterargument is in Star CloudPRNT alternatives.

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. The print connection can stay on the LAN, but the app must be able to reach the printer and produce jobs without its own cloud dependencies during an outage.

Poll (CloudPRNT, Server Direct Print): the printer asks a server for work. The interval affects latency, while server placement determines network dependencies. Star documents local and cloud CloudPRNT servers. Polling does not inherently require the internet; cloud-hosted jobs do. MQTT-enabled CloudPRNT is a separate transport profile.

Choose transport and deployment separately: latency, server operations, network reachability and the order application's offline behavior all matter.

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 a generic ESC/POS printer — and that layer is what Proxy Nodes ships.

A node is a palm-size device that sits beside the peripheral. Your software sees one HTTP/JSON API on the LAN — POST /print, GET /status, an SSE /events stream, POST /drawer/kick, GET /scans for barcode reads, GET /peers for fleet discovery over mDNS — and the node speaks ESC/POS to the printer on the other side, the only print language its firmware implements (a StarPRNT-only printer is refused by name). It also accepts raw ESC/POS on port 9100 and answers DLE EOT status queries, as an integration path for software with configurable raw ESC/POS printing. Qualify the actual POS and printer; raw drawer pulses are filtered and require a separate HTTP call. Compatibility profiles (epson-tm-m30, star-tsp100) let a node advertise a model identity too, but no point-of-sale system has yet accepted one in our presence. A replacement printer still needs qualification for its command dialect, status, layout and drawer wiring.

The shape is pure push, and the numbers are measured, not estimated: the drawer-kick round trip completes in 0.15 s, a printer and barcode scanner have bound together behind a powered USB hub on our bench in 1,012 ms (the hub is an accessory not yet qualified with the board we sell), and in shipping Nodeware nothing in the print path waits on a cloud poll or touches the internet at all. The node handles text wrapping itself — a measured 48-column default on 80 mm paper, adjustable per receipt — so tuning output is a curl, not a reflash. The shipping hardware is Proxy Node Raw, running Nodeware 1.2.55 or later.

A CloudPRNT client for the node is in development, implemented in firmware source but not yet in a released firmware image: the node polls a CloudPRNT server over HTTP, our cloud by default or one you run, and prints plain text or our print-lines JSON on a generic ESC/POS printer. Star image and markup formats are not accepted, Star's MQTT method is not implemented, and the client has not been tested against any third-party CloudPRNT server. It puts the pull shape in front of the same generic printer; see Star CloudPRNT alternatives.

With evaluation access, the digital twin exercises a subset of the local API and modeled paper/cover faults. It omits routes, does not enforce API authentication or deliver configured webhooks, and its offline toggle leaves sockets running. Qualify the actual hardware separately. More for integrators at the developers hub, and the broader survey of printing approaches (drivers, relays, agents) is in the receipt printer API guide.