Hey! We’ll get your kitchen ticket printer to stop printing garbled text and random symbols.
Before we change any ESC/POS settings, a quick scan so I know how your POS is wired:
• Brand/model of the kitchen printer (Epson TM-T88, Star TSP, Bixolon, generic ESC/POS, impact vs thermal)?
• How it’s connected: USB, network/Ethernet, serial, USB print server, or directly from a tablet?
• Symptoms: whole ticket is **gibberish characters**, or only certain lines? Any **missing items**, duplicated tickets, or extremely faint / over-dark print from the thermal head?
• Which POS / KDS system (Toast, Square, Lightspeed, Odoo POS, custom app) is sending the kitchen tickets?
Customer
Small restaurant. Thermal kitchen printer on Ethernet, generic ESC/POS compatible (Epson clone). Tickets from our POS sometimes look fine, other times they’re **garbled**, random symbols instead of text, or half of the ticket is shifted or missing.
Got it — classic ESC/POS kitchen ticket issue.
In the background, your POS sends a stream of ESC/POS commands: text, line feeds, cut, logos. If the **printer language**, **code page**, or **buffer** don’t match what the app expects, you see:
• Garbled tickets (Chinese-looking characters, boxes, “Âé┼” instead of text) → usually encoding / code page mismatch or wrong driver.
• Tickets that start okay and then turn into junk midway → often an ESC/POS buffer overflow or an image/graphics block the printer doesn’t fully understand.
• Tickets too light or burned/black → heat mode / print density is wrong for your paper or speed.
Plan: 1) Confirm the printer really runs in ESC/POS mode. 2) Match the POS app’s encoding/code page. 3) Tweak buffer/flush behavior so long tickets don’t corrupt. 4) Dial in the thermal heat mode so kitchen tickets are crisp but not smoked.
Customer
Makes sense. Where do I actually change ESC/POS or encoding? I only see the printer in Windows as a normal receipt printer, nothing about buffer or heat mode.
Step 1 — Make sure the driver and printer language are truly ESC/POS
On the POS server/PC:
1) Open Devices & Printers → right-click your kitchen printer → Printer properties.
2) Under Advanced, confirm you’re using the vendor’s **ESC/POS / thermal receipt driver**, not a generic text-only or label driver. If you see “Generic / Text Only” or a random USB driver, switch to the proper Epson/Star/Bixolon driver or the one recommended by your POS.
3) In the driver’s **Device Settings** or **Advanced** tab, look for:
• Printer language: ESC/POS (not ZPL, TSPL, Star Line Mode etc.).
• Character table / code page: pick the one your POS expects (often **CP437**, **CP858**, or **Western Europe**). This fixes kitchen printer garbled characters where accents and symbols look wrong.
4) If the POS is browser-based, check its **receipt / ticket printer settings** to be sure “ESC/POS thermal printer” is selected, not “PDF printer”. This prevents binary ESC/POS data from being wrapped in the wrong format.
Customer
The driver was set to Generic / Text Only. I changed it to the “Epson ESC/POS” one our POS vendor suggested. Tickets are more readable now, but occasionally the second half of a busy order still turns into nonsense.
Great, so language is fixed — now we deal with the **ESC/POS buffer** and ticket length.
Kitchen printers have a small input buffer. If the POS pushes one giant ESC/POS job with logos, bold formatting, and multiple cut commands, the printer can “lose its place” and start reading bytes as characters instead of commands.
Do this next:
• In the printer driver, disable “bidirectional support” and any “advanced spool format” or compression options. Send jobs as **RAW 9100 / direct** where possible so the buffer sees clean ESC/POS commands.
• In the POS settings, turn off any “image receipt” or “print ticket as graphic/PDF” option. Use pure text + ESC/POS, not a big raster image of the ticket.
• If your POS has an option for “Send cut command after each ticket” or “Flush buffer after order”, enable it. That forces the printer to execute everything and reset its buffer between tickets instead of chaining multiple kitchen orders into one long stream.
This combination usually stops long tickets from corrupting halfway through.
Customer
I found an option to disable graphic receipts and turned off bidirectional support. Garbled lines are mostly gone, but now the text is really light unless I slow the printer down.
That’s where the thermal heat mode and print density come in.
On many Epson/Star/Bixolon kitchen printers, ESC/POS includes commands to control how hard and how long the thermal head fires dots:
• Low heat / low density → quieter, faster, but pale gray tickets (hard to read in a hot kitchen).
• High heat / high density → darker tickets, but if it’s too high, logos blur and the head wears faster.
Adjust it this way:
1) Open the vendor’s **Printer Utility** (Epson TM Utility, StarPRNT, etc.) on the PC or from the web interface if the printer has one.
2) Go to Printer Settings → Print Density / Print Darkness / Heat mode.
3) Nudge density up one step at a time and test a ticket: you want dark black text without smearing or shiny burned areas.
4) If your printer exposes an ESC/POS “print density” or “energy” command, your POS vendor might let you add this to the ticket template so every kitchen ticket forces the correct heat mode.
Once density is dialed in for your paper stock, you can run the printer at normal speed and still get legible kitchen chits.
Customer
Tickets look better now. Still, once or twice a night a single ticket comes out with random symbols at the top, then prints normally again after.
Intermittent **garbled first line** tickets usually mean one of three things:
• The POS sometimes sends a job in the wrong format (e.g., different command set, UTF-8 text while the printer expects another code page).
• Another app on the network is accidentally printing to the same ESC/POS queue.
• A network or USB glitch corrupts the first few bytes (where ESC/POS initialisation lives).
Let’s harden things:
1) On the POS, verify the **kitchen printer is used only by the POS service**, not shared with Windows test prints or other apps.
2) Disable any second “kitchen” printer queue that points to the same IP/port so jobs can’t collide.
3) If the printer is on Ethernet, set a **static IP** and use a **Standard TCP/IP RAW 9100 port**. Avoid “WSD” ports which can resend or re-order data in busy environments.
4) In POS settings, make sure every kitchen template uses the same encoding and ESC/POS driver profile — no mixed “image” vs “text” tickets.
If we still see occasional junk after this, we can enable logging on the POS side and inspect exactly what bytes were sent for a bad ticket.
Customer
Static IP and RAW 9100 are set now. No random junk so far. Can we make tickets a little bolder without overheating the head? It’s hot and steamy in the kitchen.
Definitely — you just need the right mix of **heat mode, speed, and paper** for a kitchen environment:
• Use decent-quality **80 mm thermal paper**; ultra-cheap rolls force you to crank heat up and still look gray.
• In the printer utility, set **print density one step above the default** and keep speed at normal. If the printer offers “kitchen” or “high contrast” presets, start there.
• Avoid running at max darkness all day — it can shorten thermal head life. Better paper + moderate density is safer than max heat on cheap stock.
• If your printer supports ESC/POS “print density” commands, your POS vendor can embed those so **kitchen printer tickets** use a slightly darker profile than customer receipts.
That way cooks get bold, readable tickets on the line, without premature head failure.
Customer
Is this approach okay for both Epson and Star kitchen printers? We might swap brands soon.
Yes — the recipe is the same across most ESC/POS-compatible kitchen printers:
• Make sure the POS profile matches the printer family (Epson ESC/POS vs Star line mode / StarPRNT, etc.).
• Use the manufacturer’s utility to set **print density / energy** instead of relying only on POS-side “bold” fonts.
• Keep a test template that prints typical kitchen tickets (long orders, modifiers, special notes) and re-run it whenever you change brand or model.
As long as the POS is speaking the right command set and the **thermal settings** match your paper, you won’t see garbled tickets, just clean, dark text your cooks can trust during a rush.
Customer
That did it. No more garbled kitchen tickets and the print is darker but still sharp. Really appreciate the help!
Summary: When a
kitchen printer garbles tickets, the root cause is almost always a mismatch in **ESC/POS driver / language**, **code page**, or **buffer handling** — sometimes combined with bad
heat mode / print density settings.
Fix in order: install the proper ESC/POS driver, pick the correct **character table**, send jobs as RAW (no graphics receipts), and ensure the POS flushes the buffer after each ticket. Then tune the **thermal density** for your paper so text is bold but not burnt.
Want an expert to remote in, check your specific POS, and set the optimal ESC/POS commands for your kitchen printer model?
Open the chat.
How to test kitchen tickets after adjusting ESC/POS and heat mode
After you change drivers or thermal print density, always print a realistic test: a long kitchen ticket with multiple courses, modifiers and notes. Check that:
• No line shows random symbols or squares.
• Accented characters and currency signs look correct for your language and menu.
• Text is dark and crisp from top to bottom, with no fade-out on the last lines.
• Cuts happen exactly between tickets, not mid-order.
If anything looks wrong, step back through the ESC/POS driver profile, code page, and density until every test ticket looks identical, then roll those settings out to all kitchen printers on the line.
Kitchen printer garbled tickets — quick troubleshooting tips
Most “gibberish tickets” come down to the wrong driver, wrong command set, or an ESC/POS buffer that isn’t being flushed.
Quick path: switch from any **Generic / Text Only** queue to the proper ESC/POS receipt driver, set a stable code page, and send jobs over a RAW TCP/IP port. Disable graphic/PDF receipts, let the POS send plain ESC/POS text, and enable a cut/flush after each ticket so the kitchen printer resets its buffer between orders. Then use the vendor utility to raise print density just enough that cooks can read tickets instantly, even in steam and low light.
Disclaimer: This information is AI-generated and intended for general guidance only. For advice specific to your environment, please consult a verified expert on Whizz-Tech before making decisions.
Why is my kitchen printer printing garbled tickets or random symbols?
Most garbled kitchen tickets are caused by a mismatch between the POS and printer: wrong driver (Generic instead of ESC/POS), incorrect printer language, or the wrong code page/encoding. Switching to the vendor’s ESC/POS receipt driver, setting the correct character table, and sending jobs over a RAW port usually stops the random symbols.
How do I stop my ESC/POS kitchen printer from corrupting long tickets?
Disable graphic/PDF receipts and let the POS send plain ESC/POS text. Turn off bidirectional printing, use a RAW 9100 port, and enable a cut/flush after each order so the ESC/POS buffer resets between tickets. If your POS chains multiple orders into one job, work with the vendor to split them so the printer doesn’t overflow its buffer mid-ticket.
How can I make kitchen tickets darker without damaging the thermal head?
Use the manufacturer’s utility (Epson TM Utility, StarPRNT, etc.) to increase print density / heat mode one step at a time while printing test tickets. Combine moderate darkness with decent thermal paper instead of maxing out energy. Excessive heat can shorten head life and cause blurry, over-black tickets.
Will these ESC/POS fixes work if I change kitchen printer brands?
Yes. The same principles apply to most ESC/POS-compatible kitchen printers: choose the right driver/command set for the brand, match the POS encoding and code page, send jobs as RAW, and tune density for your paper. You may only need to adjust brand-specific options in the new vendor’s utility.