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 walks 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 cheapest-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 80mm 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

The top of the range is a digital twin: a service that doesn't just render receipts but behaves like the device — same ports, same discovery, same status replies, same failure modes — so your application genuinely cannot tell it from hardware.

The ProxyNodes twin (started with pnpm sim) is a plain service on your LAN:

• Accepts raw ESC/POS on TCP :9100 like any network printer — and answers DLE EOT status queries consistently with its actual simulated state.
• Serves the ProxyNode HTTP API on :8080 — POST /print, GET /status, POST /drawer/kick, and a GET /events stream of live telemetry.
• Announces itself over mDNS (_proxynode._tcp), so printer-discovery code runs for real.
• Simulates a printer, cash drawer, scale, and barcode scanner — the peripherals around the printer, not just the printer.
• Comes with 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.

That last item is the piece nothing else on this page offers. QA can finally script the ugly scenarios — "printer dies halfway through the dinner rush" — instead of physically yanking cables, and CI can run them nightly. A matching conformance suite runs the identical test set against the twin or against real hardware, so behavior verified in simulation is re-verified on the bench with the same assertions. (The twin and suite are source-open at launch; the repository isn't public yet — details on the simulator page.)

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.

Frequently asked questions

Is there a free virtual receipt printer?

Yes, several. Print-to-PDF drivers are built into Windows and macOS; virtual-printer.online renders ESC/POS in the browser; EscPosEmulator, escpos-netprinter, and escpresso are open source; and the ProxyNodes digital twin is free to run and source-open at launch.

Can I use a print-to-PDF driver to test POS receipt printing?

Only if your app prints through the OS print system. Most POS software sends raw ESC/POS bytes over TCP or USB, which never touches the OS driver stack — so a PDF driver tests nothing about that path. Use a port-9100 emulator or a digital twin instead.

What's the difference between a virtual printer and a printer emulator?

Usage overlaps, but 'virtual printer' usually means anything that captures print output (including PDF drivers), while 'emulator' implies imitating a specific printer protocol like ESC/POS. A digital twin goes furthest: it imitates the device's network behavior, status replies, and failure modes.

How do I test what happens when the printer runs out of paper?

You need fault injection. The ProxyNodes twin has a console command — 'paper out' — that makes prints fail and changes status replies exactly as a real paper-out would, so you can verify your app alerts staff instead of dropping the order silently.

Can a virtual receipt printer run in CI?

Renderers like escpos-netprinter can run headless for visual checks. For integration tests, run a digital twin as a service in the pipeline, point your app at it, and assert on behavior — including injected faults. See our CI guide for working recipes.