ESC/POS Command Builder
Compose a receipt, see the exact bytes, then send them to a printer you pick.
How this talks to your device
You compose receipt lines with alignment, weight and size, and the page assembles the ESC/POS byte stream and shows it in full before anything is sent. The bytes are the product here. ESC/POS is a stateful protocol — bold stays on until switched off, a size command applies to everything after it — so a builder that silently reset state between lines would produce output that does not match what you composed, on hardware you are about to print from. What the hex view shows is exactly what goes down the wire, in order, with nothing added. Text is encoded as Latin-1 rather than UTF-8, because receipt printers use code pages and UTF-8 bytes come out as mojibake on paper; characters outside the range become a question mark rather than a random byte, since a stray byte in an ESC/POS stream can be interpreted as a command. Sending claims the printer's interface only for the transfer and releases it immediately.
What the results mean
- Byte stream
- The complete command sequence in hex. ESC is 0x1b and GS is 0x1d — every command starts with one of them, and the bytes between are the parameters.
- Transfer status ok
- The printer accepted the bytes. It does not mean it understood them: a printer speaking a different dialect will accept the transfer and then print nothing or print garbage.
- Stalled transfer
- The printer rejected the data or is in an error state — out of paper, cover open, or a condition that has to be cleared at the printer itself.
- Cash drawer pulse
- ESC p, the standard command that fires the solenoid in a till drawer wired to the printer's DK port. It is part of ESC/POS rather than an extra, and it is how every point-of-sale system opens a drawer.
Common problems and fixes
- The transfer succeeds but nothing prints
- The printer is not speaking ESC/POS. Star printers in their native mode use a different command set entirely, and several printers need to be taken out of a line-mode or emulation setting first — usually a DIP switch or a self-test menu on the printer.
- The printer is not in the chooser
- Only devices identifying as the USB printer class are listed. A receipt printer installed with a vendor driver is often claimed by that driver, which makes it unavailable to the browser. On Windows this is common and is a driver-level restriction.
- Accented characters come out wrong
- Receipt printers use code pages, and the printer's current code page decides what byte 0xe9 renders as. Set the code page on the printer to match, or restrict the text to plain ASCII, which is safe everywhere.
- The cash drawer does not open
- Try the other pin — drawers are wired to pin 2 or pin 5 depending on the cable, and the wrong one does nothing. If neither works, the drawer's solenoid may need more voltage than the printer's port supplies, which is a cable and hardware question rather than a command one.
Frequently asked questions
What is ESC/POS?
Epson's command language for receipt printers, adopted so widely that most thermal receipt printers speak some version of it. It is a byte stream: escape sequences set state such as alignment and weight, and plain bytes are the text. It is not a standard in the formal sense, which is why dialects differ between manufacturers.
Why show me the bytes at all?
Because getting them wrong produces a printer that prints nothing, prints forever, or emits a metre of garbage — and because if you are building a point-of-sale integration, the byte stream is what you are actually working on. Seeing it before sending turns a gamble into a check.
Is it safe to send this to my printer?
The commands here are ordinary printing operations — text, alignment, feed, cut, drawer pulse. None writes to persistent memory or changes a printer setting. The worst realistic outcome is wasted paper on a printer that misinterprets a dialect difference.
Can I use this for a real point-of-sale system?
As a way to work out and verify the byte sequence, yes — that is the useful part. The sending path here is a browser talking to one USB printer that a person picked, which is not how a till runs. Take the bytes, not the transport.