Warum läuft epsjpg.de rein im Browser?

Weil EPS-Dateien typischerweise unter 50 MB liegen und das Rendering mit Ghostscript.js (WASM-Portierung des Original-Ghostscript) auf moderner Hardware schnell genug ist. Wir haben uns bewusst gegen den Upload-Weg entschieden, weil der USP der Site die echte Lokalität ist: Designer mit unveröffentlichten Logos oder vertraulichen Kundengrafiken sollen ohne Bedenken konvertieren können.

Was passiert technisch beim ersten File-Drop?

Beim ersten Drop lädt der Browser per dynamischem import() den Ghostscript.js-Bundle (rund 8 bis 12 MB WASM + JS). Das passiert nur einmal pro Session, danach ist das Modul im Speicher gecacht. Die zweite Konvertierung in derselben Session startet sofort, ohne weiteren Network-Request für die Engine. Wer das überprüfen will, öffnet die Browser-DevTools und sieht im Network-Tab den WASM-Download nur beim ersten Konvertieren.

Was ist der konkrete Nachteil gegenüber Server-Konvertierung?

Drei Punkte: erstens das einmalige Engine-Loading (8 bis 12 MB), zweitens die Begrenzung auf rund 50 MB pro Datei wegen Browser-Memory-Limits bei 300 dpi, drittens die Abhängigkeit von der Browser-Performance. Auf einem schwachen Laptop läuft eine 300-dpi-Konvertierung einer komplexen EPS langsamer als auf einem Cloud-Server mit nativem Ghostscript.

Wie kann ich verifizieren dass keine Datei übertragen wird?

Browser-DevTools öffnen (F12), Network-Tab aktivieren, dann eine EPS-Datei droppen und konvertieren. Du wirst sehen, dass beim Klick auf Konvertieren kein Request mit dem Datei-Inhalt rausgeht. Nur die WASM-Engine wird einmal geladen. Alternativ kannst du die Site offline testen: nach dem ersten Laden Internetverbindung kappen, dann konvertieren. Es funktioniert weiterhin.

Welche Engines machen Server-Upload und welche Browser-WASM?

Server-Upload: CloudConvert, Convertio, ZAMZAR, FreeConvert, eps-jpg-converter (unsere Schwester-Site). Diese Tools schicken die EPS-Datei an einen Backend, der dort ein natives Ghostscript ausführt. Browser-WASM: epsjpg.de (diese Site), Photopea (Photoshop-Klon), Squoosh (Google). Browser-WASM ist Trend, weil WASM-Performance auf moderner Hardware ausreicht und Datenschutz-by-Design wertvoller wird.

WASM-Konvertierung vs. Server-Upload: warum EPS im Browser bleibt

Zwei Wege, dieselbe Datei

Wer eine EPS-Datei in ein JPG umwandeln will, landet im Netz auf einem von zwei Architektur-Typen. Beide produzieren am Ende ein JPG, aber sie tun das auf grundverschiedenen Wegen.

Typ 1: Server-Upload. Die Seite zeigt ein Upload-Feld. Der Nutzer wählt eine EPS, der Browser schickt sie per HTTP-POST an einen Backend-Server. Dort läuft eine native Installation von Ghostscript (Artifex, gs >= 9.56) oder eine kommerzielle Konvertierungs-Engine. Der Server rendert das EPS zu Pixeln, speichert das JPG temporär und gibt einen Download-Link zurück. Beispiele: CloudConvert, Convertio, ZAMZAR, die Schwester-Site eps-jpg-converter.

Typ 2: Browser-WASM. Die Seite lädt WebAssembly-Modul (Ghostscript.js) in den Browser. Der Nutzer wählt eine EPS, die Datei wird per FileReader als ArrayBuffer eingelesen, der WASM-Interpreter rendert das EPS zu Pixeln, eine OffscreenCanvas-API erzeugt das JPG. Die Datei verlässt zu keinem Zeitpunkt den Browser. Beispiele: epsjpg.de (diese Site), Photopea, Squoosh.

Beide Wege haben Vor- und Nachteile, die je nach Anwendungsfall unterschiedlich gewichtet werden. Ein Designer mit einem unveröffentlichten Kundenlogo gewichtet Datenschutz höher als Render-Geschwindigkeit. Ein Praktikant, der schnell ein paar Stock-Logos konvertieren muss, gewichtet Geschwindigkeit höher.

Die Vergleichstabelle

<text class="label" x="180" y="60">Server-Upload</text>
<rect class="box" x="80" y="80" width="80" height="44"/>
<text class="small" x="120" y="100">Browser</text>
<text class="small" x="120" y="114">EPS</text>
<line class="arrow" x1="160" y1="102" x2="200" y2="102" marker-end="url(#a1)"/>
<rect class="box" x="200" y="80" width="80" height="44"/>
<text class="small" x="240" y="100">Server</text>
<text class="small" x="240" y="114">Ghostscript</text>
<line class="arrow" x1="280" y1="102" x2="320" y2="102"/>
<rect class="box" x="320" y="80" width="80" height="44"/>
<text class="small" x="360" y="100">JPG</text>
<text class="small" x="360" y="114">Download</text>
<text class="small" x="240" y="146">Datei verlässt den Browser</text>

<text class="label" x="540" y="60">Browser-WASM</text>
<rect class="box-alt" x="440" y="80" width="200" height="44"/>
<text class="small" x="540" y="100">Browser (Tab)</text>
<text class="small" x="540" y="114">EPS -> WASM -> JPG</text>
<text class="small" x="540" y="146">Datei bleibt im Tab</text>

<text class="head" x="360" y="200">Konsequenzen</text>
<rect class="box" x="80" y="220" width="280" height="120"/>
<text class="small" x="220" y="244">- Upload-Bandbreite nötig</text>
<text class="small" x="220" y="264">- Server-Speicher 30 min</text>
<text class="small" x="220" y="284">- Auch sehr große Files (1 GB)</text>
<text class="small" x="220" y="304">- Native Performance</text>
<text class="small" x="220" y="324">- DSGVO Art. 6 lit. b</text>

<rect class="box-alt" x="400" y="220" width="280" height="120"/>
<text class="small" x="540" y="244">- 8-12 MB Engine-Load einmal</text>
<text class="small" x="540" y="264">- Limit rund 50 MB pro Datei</text>
<text class="small" x="540" y="284">- Offline-fähig nach 1. Load</text>
<text class="small" x="540" y="304">- Browser-CPU-Performance</text>
<text class="small" x="540" y="324">- DSGVO Art. 6 lit. f</text>

Server-Upload schickt die EPS-Datei durch das Netz, Browser-WASM lässt sie im Tab. Die Konsequenzen unterscheiden sich in Datenschutz, Latenz, Limits und Rechenlast.

Die einzelnen Achsen im Detail:

Latenz und Bandbreite. Beim Server-Upload muss die EPS-Datei einmal hochgeladen und das JPG einmal heruntergeladen werden. Bei einer 5-MB-EPS und durchschnittlicher Heim-Bandbreite (25 Mbit/s Upload) sind das rund 2 Sekunden Upload plus Server-Verarbeitung plus Download. Browser-WASM hat keinen Upload, dafür aber einen einmaligen Engine-Download von 8 bis 12 MB beim ersten Konvertieren der Session. Bei zwei Konvertierungen in Folge ist Browser-WASM ab der zweiten Datei in der Regel schneller, weil der Engine-Load entfällt.

Datenschutz. Beim Server-Upload verlässt die Datei den Browser des Nutzers und wird auf einem Server gespeichert. Auch bei 30-Minuten-Auto-Delete ist sie in diesen 30 Minuten ein Angriffsziel und ein DSGVO-relevantes Datum. Bei Browser-WASM verlässt die Datei den Browser nicht. Für Designer mit vertraulichen Kundengrafiken, unveröffentlichten Logos oder geheimen Produkt-Mockups ist das ein konkreter Unterschied.

Dateigrösse. Server-Pipelines können sehr große EPS-Dateien rendern, oft bis 1 GB oder mehr, weil sie Cloud-Server-RAM nutzen. Browser-WASM ist durch das Browser-Memory-Limit gebremst. Auf modernen Desktop-Browsern (Chrome 120 plus, Firefox 121 plus) liegt die praktische Obergrenze bei rund 50 MB EPS bei 300 dpi. Wer eine 200-MB-CAD-EPS rendern will, ist auf einem Server besser aufgehoben.

Render-Performance. Native Ghostscript auf einem Server-CPU ist 30 bis 50 Prozent schneller als die WASM-Portierung im Browser. Für eine einfache Logo-EPS (10 KB, 150 dpi) bemerkt der Nutzer den Unterschied nicht, beide brauchen unter einer Sekunde. Für eine komplexe Vektorgrafik mit 1000 Pfaden bei 300 dpi kann der Unterschied zwischen 12 und 18 Sekunden liegen.

Rechtsgrundlage DSGVO. Server-Upload braucht in der Regel Art. 6 Abs. 1 lit. b DSGVO (Vertragsanbahnung) als Rechtsgrundlage für die kurzzeitige Server-Verarbeitung. Browser-WASM braucht das nicht, weil keine personenbezogenen Daten verarbeitet werden. Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse) reicht für den reinen Webseiten-Betrieb mit Logs.

Wer macht was: ein kurzer Marktüberblick

Die großen kommerziellen Konvertierungs-Dienste setzen alle auf Server-Upload. CloudConvert hat das ganze Geschäftsmodell auf Server-Konvertierung aufgebaut und bietet über 200 Format-Konvertierungen an, von EPS bis MP4. Convertio und ZAMZAR funktionieren ähnlich. Diese Anbieter haben monatliche Limits in der Gratis-Stufe (10 oder 25 Dateien pro Monat) und kostenpflichtige Pakete für mehr.

Die Schwester-Site eps-jpg-converter aus dem AKARA-Portfolio setzt ebenfalls auf Server-Upload, dort allerdings mit eigener Ghostscript-Pipeline als Netlify-Function im selben Repo. Vorteil: grössere Datei-Grössen, schnellere Konvertierung bei komplexen EPS. Nachteil: Datei muss kurzzeitig auf dem Server liegen.

Browser-WASM-basierte EPS-zu-JPG-Konverter sind 2026 noch selten, weil die Ghostscript-WASM-Portierung relativ frisch ist (ps-wasm von ochachacha auf GitHub, 2023). epsjpg.de positioniert sich genau in dieser Nische: schneller als manülles Herunterladen von Inkscape, datenschutzfreundlicher als CloudConvert, ohne Anmeldung und ohne Limits.

Was die WASM-Engine konkret macht

Wenn ein Nutzer eine EPS-Datei in das Drop-Feld zieht, passiert technisch Folgendes:

Der Browser liest die Datei per FileReader-API als ArrayBuffer. Das ist eine reine RAM-Operation, kein Network-Request.
Beim ersten File-Drop pro Session wird Ghostscript.js per dynamischem import() geladen. Der WASM-Bundle ist rund 8 bis 12 MB gross und wird vom Browser gecacht.
Die WASM-Engine erhält den ArrayBuffer und parst die EPS-Datei nach Adobe-Spec 3.0. Sie liest die BoundingBox, interpretiert die PostScript-Operatoren und rendert die Vektorgrafik in einen Pixel-Buffer.
Eine OffscreenCanvas-API empfängt den Pixel-Buffer und ruft convertToBlob() mit Mime-Type image/jpeg und der gewählten Qualität (1 bis 100).
Der Blob wird per Object-URL als Vorschau angezeigt und steht für den Download bereit.

Die ganze Sequenz läuft im Browser-Tab, ohne dass die Datei oder ein Hash davon das Gerät verlässt. Wer das verifizieren will, öffnet die DevTools, schaltet auf den Network-Tab und konvertiert eine Datei. Es wird kein POST-Request mit dem Datei-Inhalt sichtbar sein.

Wann der Server gewinnt

Es gibt Fälle, in denen Server-Upload die bessere Wahl ist:

Sehr große Dateien (über 50 MB EPS). Das Browser-Memory-Limit ist ein harter Stop. Wer eine 200-MB-Datei rendern will, muss zum Server-Pipeline-Tool greifen.
Sehr schwache Hardware (alter Laptop, mobiles Gerät). Wenn der Browser zu wenig RAM und CPU hat, ist ein Cloud-Server schneller.
Massen-Konvertierung im API-Modus. Wer programmatisch 1000 EPS-Dateien pro Tag konvertieren will, nutzt eine HTTP-API gegen einen Server-Endpunkt, nicht einen Browser-Tab.

Für alle anderen Fälle (ein paar EPS-Dateien pro Tag, normale Hardware, normale Datei-Grössen) ist Browser-WASM in praktisch jeder Achse besser oder gleich gut: schneller bei wiederholten Konvertierungen, datenschutzfreundlicher, ohne Limits, offline-fähig.

Was bleibt zu prüfen

Vor der Konvertierung lohnt sich ein kurzer Check: Liegt die Datei unter 50 MB? Habe ich einen modernen Browser (Chrome 120 plus, Firefox 121 plus, Safari 16.4 plus)? Wenn ja, ist Browser-WASM die saubere Wahl. Wenn nein, lohnt der Wechsel zur Schwester-Site eps-jpg-converter, die das gleiche Tool mit Server-Pipeline anbietet.