Virtual Receipt Printer for Dev and Testing

A virtual receipt printer is software that stands in for a thermal printer: your app "prints," and instead of paper you get an image, a PDF, a browser preview, or a fully simulated device on the network. Which kind you need depends entirely on the question you're trying to answer — "does this receipt look right?" needs a renderer, while "does my point-of-sale handle a paper jam?" needs something that can fake the jam.

This guide covers the whole range, from print-to-PDF drivers to a network digital twin, and ends with a decision table so you can pick in thirty seconds.

The four jobs people hire a virtual printer for

"Virtual receipt printer" means at least four different things depending on who's searching:

1. Proofing a design. A designer or product manager wants to see a receipt — logo, spacing, totals — without owning a printer.
2. Developing print code. A developer is generating ESC/POS commands and wants fast visual feedback while iterating.
3. QA and troubleshooting. A tester wants to reproduce what happens when the printer misbehaves: out of paper, cover open, unplugged.
4. Automated testing (CI). A team wants the build to fail if printing breaks — with no printer within a mile of the build server.

Each job has a different right answer. Working through them simplest-first:

Print-to-PDF and print-to-image drivers

If your application prints through the operating system's normal print dialog (a browser page, a desktop POS using OS drivers), the built-in Microsoft Print to PDF on Windows or Save as PDF on macOS is a perfectly good virtual printer. Commercial virtual printer drivers go further — capturing output as PNG/JPEG, watermarking, auto-saving to a folder — and you can usually configure a custom paper size around 80 mm wide to approximate receipt stock.

• Good for: design proofs, archiving what would have printed, demoing receipt layouts in documents.
• The catch: real receipt printing in POS systems mostly doesn't go through OS print drivers. It sends raw ESC/POS bytes straight to the printer over TCP or USB. A PDF driver never sees those bytes, so this route tests nothing about an actual POS integration. There are also iPad and Android apps that render sample receipts — same category, same limitation.

If your print path is raw ESC/POS, keep reading.

Online receipt renderers

virtual-printer.online is a hosted page where you send ESC/POS data and see the rendered receipt. Zero install, so it's the fastest possible answer to "what do these bytes draw?" The related receiptline project takes the opposite approach — a markdown-like receipt language with an open-source renderer — which is pleasant if you control both ends.

• Good for: one-off checks, sharing a rendered receipt with a teammate, learning ESC/POS.
• The catch: your application can't connect to a web page as if it were a printer. Nothing about your transport, timeouts, or error handling is exercised.

Developer-grade ESC/POS emulators

The next step up: open-source emulators that listen on TCP port 9100 — the port real network receipt printers use — and render whatever your app sends. Point your POS at your laptop's IP and print.

• EscPosEmulator (roydejong): desktop app, receipt appears in a window. The standard choice for interactive development.
• escpos-netprinter: runs in Docker, renders jobs to HTML — the most automatable renderer.
• escpresso: renders received jobs in a browser preview.

Now your app's real network code path runs, and that's genuine progress over a PDF driver. What these still can't do: talk back. Real printers answer status queries (DLE EOT — explained here) telling the POS about paper, cover, and errors, and real printers fail in ways your software must handle. The renderers accept bytes and stay silent. The full comparison — including exactly which emulator does what — is in the ESC/POS emulator guide.

• Good for: iterating on receipt layout against your real print path.
• The catch: one-directional. No status, no faults, mostly GUI apps that don't fit CI.

A network digital twin

A digital twin provides a software test target for selected device behavior: network requests, status replies and injected faults. It lets your application exercise those paths without a printer, but it cannot reproduce every hardware failure or establish compatibility with a physical installation.

The Proxy Nodes twin requires access to the developer workspace; it is not a standalone public download or published npm package. Request evaluation access before planning a trial or CI dependency. With that checkout and its dependencies installed, run from the workspace root using its pinned Node and pnpm versions:

pnpm sim --host 127.0.0.1 --no-mdns --no-beacon
# Local-only test: HTTP :8080, raw ESC/POS :9100, interactive fault console

This command binds only to your computer and disables discovery. For a LAN discovery test, use an approved test network and the default bind/discovery settings instead. The simulator does not enforce the device's API authentication.

From another terminal, read its simulated state:

curl -s localhost:8080/status          # printer, drawer, scanner state as JSON
printf '\x10\x04\x01' | nc -w 1 localhost 9100 | od -An -tx1
# DLE EOT 1: one simulated status byte, printed in hex

What you get:

• Raw ESC/POS on TCP :9100 like any network printer — including DLE EOT status replies that stay consistent with the simulated state. Inject a paper-out and the status byte changes exactly as the spec says it should.
• The printing side of the Proxy Nodes HTTP API: POST /print, GET /status, a live SSE stream at GET /events, GET/PUT /config, POST /drawer/kick, POST /raw, and GET /peers — validated by the same schema Nodeware 1.2.55 answers with on a physical node. It also answers GET and DELETE /scans, GET /scale and GET /devices/unknown in the device's shapes, though its scan log never records a rejected read and /devices/unknown always reports nothing present. Not every node route is there: it has no /bootlog, /network, /compose or /restart, and it does not enforce apiMode.
• Optional mDNS announcement (_proxynodes._tcp) for testing discovery on a multicast-capable test network. The local-only command above disables it.
• The peripherals around the printer, not just the printer: a cash drawer, a barcode scanner and a scale you drive from the console, so their events reach your app.
• A fault-injection console: type paper out, cover open, or offline and the virtual hardware breaks on command. Type weight 1.25 or scan 0123456789 and the scale and scanner produce data.

The offline command changes the simulated node's online state; it does not shut its HTTP or TCP listeners. Test connection refusal, dropped sockets and timeouts separately. Paper and cover faults exercise the modeled printer response, not USB disconnection, brownouts, jams or real cutter behavior.

Conformance assertions can run against the twin and a physical node. Passing the twin checks only the behaviors exercised in software; rerun applicable checks on the exact firmware, printer and cable/power setup before deployment. The twin omits some routes, does not enforce API authentication, and does not deliver configured webhooks. Simulator scope and access describes those boundaries.

Which do you need?

Two rules of thumb fall out of the table:

• If the output is for human eyes, a renderer is enough. Don't stand up a network service to check a logo.
• If the output is for a machine — your POS, your error handler, your retry logic — you need a virtual printer that can answer back and misbehave. A test double that never fails only proves your code works on days when nothing goes wrong.

For the wider context of how apps drive receipt printers in the first place — raw TCP, vendor SDKs, local HTTP APIs — see the receipt printer API guide, and browse the rest of the developer guides.