Ratgeber › ZPL aus dem Browser drucken

ZPL aus dem Browser drucken

Veröffentlicht: 2026-08-27

Früher oder später soll eine Web-Anwendung ein Etikett auf einem Thermodrucker ausgeben, und der erste Versuch ist immer derselbe: aus JavaScript einen Socket zum Drucker öffnen. Das geht nicht — und warum es nicht geht, zeigt direkt die Muster, die funktionieren.

Warum der direkte Weg nicht funktioniert

Roher Thermodruck heißt: Bytes auf TCP-Port 9100 schreiben. Browser stellen bewusst keine API für beliebige TCP-Sockets bereit — Seiten- JavaScript spricht HTTP, WebSocket und WebRTC, und alle drei brauchen einen kooperierenden Server auf der Gegenseite. Ein Etikettendrucker auf Port 9100 ist kein solcher Server: kein HTTP, kein Handshake. Die Einschränkung ist eine Sicherheitsgrenze, kein fehlendes Feature; keine Bibliothek umgeht sie.

Muster 1 — der Server leitet weiter

Der Browser schickt das Etikett an Ihr Backend; das Backend öffnet den Socket zum Drucker und leitet die Bytes weiter. Für Lager- und Backoffice-Anwendungen ist das die Standardantwort: Drucker und Server liegen im selben Netz.

Gut: keine Software auf dem Arbeitsplatz, Protokoll und Wiederholung an einer Stelle, Druckerdaten erreichen den Browser nie.
Preis: der Server muss den Drucker erreichen können — steht der Drucker im Kundennetz und Ihr Dienst in der Cloud, fällt das Muster aus.

Muster 2 — ein lokaler Helfer am Arbeitsplatz

Neben dem Browser läuft ein kleines Programm, lauscht auf localhost, und die Seite schickt ihm das Etikett per HTTP; der Helfer schreibt auf Port 9100. So arbeiten die meisten "Webdruck"-Werkzeuge der Hersteller, und es ist das einzige Muster, das einen für den Server unsichtbaren Drucker erreicht.

Gut: funktioniert mit Druckern im Netz des Nutzers, auch bei cloud-gehosteten Anwendungen.
Preis: auf jedem Arbeitsplatz muss etwas installiert und aktuell gehalten werden; für den Aufruf von localhost muss der Helfer CORS und auf HTTPS-Seiten die Mixed-Content-Regeln bedienen.

Muster 3 — rendern und den Druckdialog des Browsers nutzen

ZPL in Bild oder PDF wandeln, anzeigen, und der Bediener druckt über den normalen Treiber. Keine Sockets.

Gut: läuft überall, ohne Installation; die richtige Antwort für gelegentlichen Druck oder wenn der "Drucker" in Wahrheit ein Bürolaser ist.
Preis: der Treiber rastert die Seite, Barcodekanten hängen davon ab, und Seitenskalierung kann das Etikett stumm umdimensionieren. Für scannbare Barcodes in Masse sind Muster 1 und 2 sicherer — die Begründung steht in PDF oder ZPL.

Was Sie auch wählen: erst das Etikett ansehen

Port 9100 kennt kein Rückgängig — sobald der Auftrag ankommt, bewegt der Drucker Material. Den Auftrag vorher im Browser zu rendern kostet nichts und fängt die strukturellen Probleme ab: Felder außerhalb des Etiketts, ein fehlender Abschluss, nicht kodierbare Barcodedaten. Fügen Sie ihn in den ZPL-Viewer ein oder rufen Sie die Render-API aus demselben Backend auf, das später sendet. Die Betriebssystem-Seite der Auslieferung steht in ZPL an einen Netzwerkdrucker senden.

Häufig gestellte Fragen

Kann JavaScript ZPL direkt an einen Drucker senden?

Nein. Roher Thermodruck schreibt Bytes auf TCP-Port 9100, und Browser bieten keine API für beliebige TCP-Sockets — nur HTTP, WebSocket und WebRTC, die alle einen kooperierenden Server brauchen. Ein Drucker auf Port 9100 spricht keines davon. Das ist eine Sicherheitsgrenze; keine Bibliothek umgeht sie.

Wie drucken Web-Anwendungen dann ZPL?

Drei Muster: Das Backend leitet den Auftrag an Port 9100 weiter (Netzzugriff nötig), ein kleiner lokaler Helfer lauscht auf localhost und reicht weiter (Installation je Arbeitsplatz), oder das Etikett wird als Bild bzw. PDF gerendert und über den normalen Treiber gedruckt (ohne Installation, aber der Treiber rastert den Barcode).