Print from a web app

A browser cannot talk to a printer. It can open a print dialog, and that is the whole of it. Here is what that rules out, and what a cloud print API does instead.

What `window.print()` can and cannot do

window.print() hands the current page to the operating system's print dialog. That is genuinely the right answer for "let the user print this invoice". It is the wrong answer for almost everything else a business app needs, because:

Someone has to click. There is no silent printing from a browser, by design.
You cannot choose the printer. The user picks, every time.
You cannot print from your server. A nightly batch of packing slips has no browser open.
You are printing the browser's rendering of a page, not your PDF, and not the raw bytes a receipt or label printer expects.

The usual workarounds are a kiosk-mode browser with printing pre-configured, or a print server on the customer's network that you somehow reach. The first is fragile and only works on machines you control. The second means opening an inbound port on someone else's network, which is the part that never gets approved.

The outbound agent model

PrintSocket puts a small agent on the machine the printers are attached to. It connects outbound over a WebSocket and stays connected. Nothing on the customer's network has to be reachable from the internet: no port forwarding, no VPN, no static IP, no firewall exception.

The agent reports every printer queue the machine can see, with capabilities, and keeps that list current. Your server then prints by making an HTTP call to us, and we hand the job down the connection the agent already opened.

curl https://api.printsocket.com/v1/jobs \
  -H "Authorization: Bearer sk_test_..." \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: order-12345" \
  -d '{
    "printer_id": "prn_8f2k1",
    "title": "Order #12345 packing slip",
    "content": { "format": "pdf", "url": "https://example.com/slip.pdf" },
    "options": { "paper": "A4", "duplex": "long_edge" }
  }'

That call comes from your backend, not from the browser. Your API key stays on your server, which is the point: a key in front-end JavaScript is readable by anyone who opens the network tab.

Build it before you own a printer

A test-mode key (sk_test_) gets a virtual device and printer that simulates the whole job lifecycle, queued → sent → printing → succeeded. You can write and finish the integration, including the failure paths, before any hardware is involved. Jobs to the virtual printer never count toward plan limits, on any plan.

Test-mode data is separate from live data, so a real printer you enroll in test mode can never appear in the fleet your production code enumerates.

What this does not do

There is no browser-only mode. Something has to run on a machine that can see the printer, and that something is the agent. If nobody can install software on the target machine, this is not the tool.
It does not render your document. You send a PDF, or raw bytes for a receipt or label printer. Turning HTML into a PDF is your side of the line.
Printing is not instant when the machine is off. A job waits queued until the device reconnects, or until it expires. Set queue_if_offline: false if you would rather be told immediately.

Start free Read the docs

Printing to a receipt or label printer instead? See ESC/POS printing from an API and the ZPL label printing API. Weighing parcels? Read a USB shipping scale over HTTP.

Print from a web app

What window.print() can and cannot do

The outbound agent model

Build it before you own a printer

What this does not do

What `window.print()` can and cannot do