Die Entscheidung am Anfang
Als JNRT Pixel entstand, gab es zwei mögliche Bauweisen. Variante A, der Industriestandard: Nutzer laden Bilder hoch, ein Server komprimiert sie, das Ergebnis kommt zurück. Variante B: Die gesamte Verarbeitung passiert im Browser des Nutzers, und es gibt schlicht keinen Server, der Bilder entgegennehmen könnte. Wir haben uns für B entschieden — und zwar nicht aus Marketing-Gründen, sondern aus einem einfachen Gedanken: Was wir nie bekommen, können wir nie verlieren. Keine Datenbank mit fremden Urlaubsfotos, keine Ausweiskopien in einem Upload-Ordner, kein Leak-Risiko, keine Löschfristen-Diskussion. Die Datenschutzerklärung für die Bildverarbeitung passt in einen Satz.
Wie das technisch funktioniert
Das Fundament ist unspektakulärer, als viele vermuten: die Canvas-API, die seit Jahren in jedem Browser steckt. Der Ablauf beim JPG-Komprimieren sieht so aus:
- Du ziehst ein Bild in die Drop-Zone. Der Browser liest die Datei aus — von deiner Festplatte in den Arbeitsspeicher deines Rechners, nicht übers Netz.
- Das Bild wird auf ein unsichtbares Canvas-Element gezeichnet, bei Bedarf gleich in der Zielgröße (das erledigt das Skalieren).
- Die Methode
canvas.toBlob()kodiert den Canvas-Inhalt neu — als JPG, PNG oder WebP, mit der Qualitätsstufe, die du am Regler eingestellt hast. - Das Ergebnis bekommst du als Download angeboten. Bei mehreren Bildern packt eine JavaScript-ZIP-Bibliothek alles in ein Archiv — auch das lokal.
In den Entwickler-Werkzeugen deines Browsers kannst du das übrigens nachprüfen: Netzwerk-Tab öffnen, Bild verarbeiten — es taucht kein Upload-Request auf. Diese Nachprüfbarkeit ist uns wichtiger als jedes Datenschutz-Versprechen in Textform.
Was uns die Entscheidung schenkt
- Keine Limits. Server-Dienste begrenzen Dateigröße und Anzahl, weil jede Verarbeitung sie Rechenzeit kostet. Bei uns rechnet dein Rechner — 50 Bilder im Stapel kosten uns dasselbe wie eins: nichts.
- Geschwindigkeit. Der Upload entfällt komplett. Bei einem 4-MB-Foto über eine durchschnittliche Leitung ist der Transfer oft langsamer als die eigentliche Kompression.
- Es funktioniert offline. Einmal geladen, arbeiten die Tools auch im Flugzeug weiter.
Was sie uns kostet — die ehrliche Seite
Werkstatt-Bericht heißt: auch die Schattenseiten gehören auf den Tisch.
- Wir können nur, was dein Browser kann. Die Canvas-API kodiert JPG, PNG und WebP — aber kein AVIF (Encoding wird bislang kaum unterstützt) und kein HEIC. Ein Server mit eigenen Codecs könnte das; wir bewusst nicht. Warum wir trotzdem keinen HEIC-Knopf einbauen, der heimlich doch hochlädt, steht im eigenen Werkstatt-Bericht.
- Der Arbeitsspeicher deines Geräts ist die Grenze. Ein 100-Megapixel-Panorama entpackt im Speicher auf mehrere hundert Megabyte — auf einem älteren Smartphone kann das den Tab überfordern. Ein Server-Dienst mit dicker Hardware hätte hier mehr Reserven.
- Farbmanagement bleibt Basis-Niveau. Browser rechnen intern meist in sRGB. Für Web-Bilder ist das genau richtig; wer Adobe-RGB-Fotos für den Druck aufbereitet, braucht weiterhin ein Desktop-Programm mit ICC-Profilverwaltung.
Für die Aufgaben, für die unsere Tools gebaut sind — Bilder fürs Web, für Bewerbungen, für Messenger und Portale aufbereiten — spielt keine dieser Grenzen eine praktische Rolle. Aber es wäre unehrlich, sie zu verschweigen.
Ein Nebeneffekt, den wir nicht geplant hatten
Die Architektur-Entscheidung hat unser Angebot geformt: Weil es keinen Server gibt, gibt es auch keine Konten, keine „3 Bilder pro Tag kostenlos"-Schranke und keinen Premium-Plan, der die Limits aufhebt. Die Seite finanziert sich über Werbung — das legen wir auf der Redaktions-Seite offen — und die Tools bleiben vollständig nutzbar, ob mit oder ohne Werbe-Einwilligung.
Selbst ausprobieren
Der schnellste Weg, sich ein Urteil zu bilden: ein Bild durch Komprimieren, Skalieren oder den Konverter schicken — mit offenem Netzwerk-Tab, wenn du uns nicht glauben willst. Genau so würden wir es an deiner Stelle auch machen.