Wie RoundCut funktioniert

Technische Details, was jedes Tool tut, wo es läuft und wie Sie es selbst überprüfen können.

Die kurze Antwort

RoundCut nutzt eine hybride Architektur: Die meisten Werkzeuge laufen komplett in deinem Browser ohne jeden Upload, und eine Handvoll schickt eine einzelne Netzwerkanfrage durch unsere eigene Infrastruktur, wenn der Browser die Qualität nicht erreichen kann, immer mit einer unsichtbaren clientseitigen Ausweichlösung. Wir sagen dir, auf welchem Pfad du bist, in jedem Werkzeug und auf dieser Seite.

Die Tabelle unten ist repräsentativ, nicht vollständig (regelmäßig kommen neue Werkzeuge dazu). Sie zeigt je ein Beispiel für jede Art von Pfad:

BeispielwerkzeugWo die Arbeit passiert
Circle Crop (nur Browser)100 % in deinem Browser, Canvas API. Kein Upload, funktioniert offline.
Komprimierungsvorschau (nur Browser)100 % in deinem Browser, canvas.toBlob. Kein Upload. Der Regler bleibt sofort.
Finaler Komprimierungsdownload (serverberührend)Ein Hin und Her zu unserem Dienst unter api.roundcut.com.br (Fastify + sharp + libvips auf einem VPS in Deutschland), mit einer Browser-Ausweichlösung.
Hintergrund entfernen (serverberührend)Ein Hin und Her zu einem Cloudflare Worker, der BiRefNet auf den Edge-GPUs von Cloudflare ausführt, mit einer WebAssembly-Ausweichlösung in deinem Browser, wenn die Cloud nicht erreichbar ist.

Zuschneiden, Größenänderung, Formatkonvertierung (außer AVIF-Kodierung) und die Komprimierungsvorschau laufen alle vollständig in deinem Browser. Hintergrund entfernen, der Komprimierungsdownload, KI-Hochskalierung, AVIF-Kodierung und PDF mit mehreren Bildern leiten jeweils eine einzelne Anfrage weiter und fallen auf den Browser zurück, wenn die Cloud nicht erreichbar ist.

Du kannst die clientseitigen Aussagen in etwa 30 Sekunden überprüfen: Öffne DevTools → Netzwerk, leere das Protokoll, nutze dann ein reines Browser-Werkzeug wie Circle Crop oder den Regler der Komprimierungsvorschau, und du wirst sehen, dass keine Anfrage mit den Bytes deines Bildes die Seite verlässt. Bei den serverberührenden Werkzeugen siehst du genau einen Upload pro Vorgang, an benannte Endpunkte.

Warum hybrid

Die meisten Online-Bildwerkzeuge sitzen an einem Extrem: alles-auf-einen-Server-hochladen (du wartest auf das Hin und Her und der Betreiber behält deine Datei) oder alles-im-Browser (du zahlst bei den Kodier- und KI-Schritten mit Qualität und Geschwindigkeit). Kein Extrem gewinnt überall.

Wir haben clientseitig gewählt, wo Browser bereits hervorragend sind, das <canvas>-Element erledigt Zuschneiden, Drehen, Größenänderung und die verlustbehaftete Vorschau-Kodierung in JPG/WebP, und serverseitig, wo der Browser noch messbar verliert:

  • Bildkomprimierung, beim finalen Download. Serverseitiges sharp + libvips 8.17 erzeugt Dateien, die bei gleicher visueller Qualität Byte für Byte 10-15 % kleiner sind als Browser-Encoder, und gibt Zugang zu AVIF-Geschwindigkeits-/Chroma-Feinabstimmung und JPEG-XL-Ausgabe, die der Browser nicht freigibt. Der Regler und die Vorschau laufen weiter in deinem Browser, damit das Ausprobieren sofort bleibt, nur der “Download”-Tipp geht durch unseren Dienst.
  • KI-Hintergrundentfernung und KI-Hochskalierung, auf dem Standardpfad. Die Modelle (BiRefNet für die Segmentierung, Superauflösung für das Hochskalieren) brauchen eine echte GPU, um in Sekunden fertig zu werden. Die Ausweichlösungen im Browser funktionieren, sind aber langsamer und liefern bei Haaren, Fell und feinen Kanten ein sichtbar gröberes Ergebnis.
  • AVIF-Kodierung, bei der Konvertierung. Der AVIF-Encoder im Browser ist auf manchen Geräten langsam, daher leitet die AVIF-Ausgabe eine Anfrage an den Komprimierungs-Worker weiter, mit einer Browser-Kodierung im Haupt-Thread als Ausweichlösung.

Der Preis, den wir für die Serverseite auf diesen Pfaden akzeptieren, ist ein Hin und Her pro Vorgang. Der Preis, den wir vermeiden, indem wir überall sonst clientseitig bleiben, ist die Hin-und-Her-Gebühr bei den Teilen des Ablaufs, die am schnellsten iterieren.

Die Pipeline, Schritt für Schritt

1. Du wählst eine Datei aus

Über die Dateiauswahl, per Drag-and-drop oder per Einfügen übergibt der Browser JavaScript ein File-Objekt. JavaScript liest die Bytes mit FileReader oder Blob.arrayBuffer(). Zu keinem Zeitpunkt in diesem Schritt wird die Datei über das Netzwerk gesendet, unabhängig davon, welches Werkzeug du nutzt.

2. Der Browser dekodiert das Bild

Moderne Browser dekodieren JPG, PNG, WebP, GIF und AVIF nativ. Wir nutzen createImageBitmap(), um die Rohbytes in eine Bitmap zu verwandeln, mit der die GPU arbeiten kann, abseits des Haupt-Threads. Für HEIC in Browsern, die es nicht nativ dekodieren, fallen wir auf einen WebAssembly-Decoder zurück, der lokal in deinem Browser läuft.

3. Das Werkzeug tut seine Arbeit, hier teilen sich die Pfade

  • Reine Browser-Werkzeuge (Zuschneiden, Größenänderung, Formatkonvertierung zu PNG/JPEG/WebP, die Komprimierungsvorschau). Eine Canvas-2D-Pixeltransformation oder ein WebAssembly-Codec kodiert die Bitmap lokal neu. Das Ergebnis ist ohne jeden Upload fertig. Cropper.js übernimmt den interaktiven Zuschnitterahmen für die Zuschneidewerkzeuge, und canvas.toBlob übernimmt die Neukodierung der Vorschau. Vollständig in deinem Browser.
  • Komprimierung, Download. Wenn du auf “Download” tippst, wird das Bild einmal an api.roundcut.com.br gesendet (ein Fastify-Dienst auf einem von Hostinger betriebenen VPS in Deutschland, Node 24 + sharp 0.34 + libvips 8.17, dieselben C-Bibliotheken, die Squoosh auf seinem Server-Pfad nutzt). Es wird mit denselben Parametern neu kodiert, die du in der Vorschau eingestellt hast, und die Bytes werden zurück zu deinem Browser gestreamt. Der Dienst hält einen mandantenisolierten, inhaltsadressierten Cache (ein Hash der Eingabebytes + Parameter), begrenzt auf 500 MB, sodass das erneute Herunterladen desselben Bildes mit denselben Einstellungen die zwischengespeicherten Bytes wiedergibt, der Cache ist nicht nach dir, IP oder Dateiname indexiert. Wenn der Dienst nicht erreichbar ist, fällt das Werkzeug auf das Vorschau-Blob im Browser zurück.
  • Hintergrund entfernen, Standard-Cloud-Pfad. Das Bild wird einmal zu einem Cloudflare Worker hochgeladen, in einem privaten R2-Bucket zwischengelagert, durch Cloudflares cf.image.segment-Transformation verarbeitet, die das BiRefNet-Modell auf den Edge-GPUs von Cloudflare ausführt, und der Ausschnitt wird zurückgestreamt. Das zwischengelagerte R2-Objekt wird durch eine R2-Lebenszyklusregel innerhalb einer Stunde gelöscht, unabhängig vom Ergebnis. Ein typisches Foto ist in 1-3 Sekunden fertig. Tägliche Grenzen pro IP und ein Upload-Limit von 5 MB halten die kostenlose Stufe tragbar.
  • Andere cloud-gestützte Werkzeuge (KI-Hochskalierung, AVIF-Kodierung, PDF mit mehreren Bildern) folgen derselben Form: eine Anfrage an benannte Infrastruktur (eine Cloud-Bild-API für die Superauflösung, der Komprimierungs-Worker für die AVIF-Kodierung, unser VPS-Dienst für PDF mit mehreren Bildern), das Ergebnis wird zurückgestreamt, und eine unsichtbare Browser-Ausweichlösung, falls diese Anfrage scheitert.
  • WebAssembly-Ausweichlösung. Wenn der entsprechende Cloud-Pfad nicht erreichbar ist (dein Netzwerk fällt aus, du bist hinter einer strengen Firewall, das Tageskontingent ist voll oder die Datei überschreitet die Cloud-Grenze), wechselt das Werkzeug nahtlos zu einem lokalen Modell oder Codec, der in deinem Browser läuft, zum Beispiel das ISNet-Hintergrundentfernungsmodell über ONNX Runtime Web mit WebAssembly. Der erste Lauf lädt das Modell herunter und ist langsamer, spätere Läufe sind schneller. Kein Upload auf diesen Ausweichpfaden, du kannst es in den DevTools überprüfen.

4. Du lädst das Ergebnis herunter

Die Ausgabe-Bitmap wird in ein Blob kodiert, in eine object URL verpackt und dem Standard-Dateispeicherdialog deines Browsers angeboten. Die Datei erscheint auf deiner Festplatte.

Wie du es selbst überprüfst

Wähle, was du bevorzugst:

Methode 1. Den Netzwerk-Tab beobachten

  1. Öffne RoundCut in einem frischen Tab und öffne DevTools → Netzwerk.
  2. Nutze ein reines Browser-Werkzeug, Circle Crop oder den Regler der Komprimierungsvorschau. Du wirst nur Anfragen für HTML/CSS/JS/Schriften sehen, dazu die entsprechenden WebAssembly-Module bei der ersten Nutzung. Keine Anfrage wird die Bytes deines Bildes tragen.
  3. Nutze nun ein serverberührendes Werkzeug, Komprimierung → Download oder Hintergrund entfernen. Du wirst genau ein POST sehen, das dein Bild trägt, und eine Antwort mit dem Ergebnis. Fahre über eine Anfrage, um Größe und Zeit zu sehen.

Die Spalte “Initiator” sagt dir, welches Skript jede Anfrage ausgelöst hat, und die Spalte “Typ” sagt dir, was gesendet wurde. Wir verbergen keines von beiden.

Methode 2. Die Werkzeuge offline nutzen

  1. Lade eine beliebige RoundCut-Werkzeugseite. Nutze Hintergrund entfernen einmal an einem kleinen Bild, damit das ISNet-Modell im Browser zwischengespeichert wird.
  2. Öffne DevTools → Netzwerk → setze ein Häkchen bei Offline (oder schalte das WLAN aus).
  3. Lade die Seite neu, die statischen Inhalte sind zwischengespeichert, also lädt sie weiterhin.
  4. Probiere die Werkzeuge aus:
    • Reine Browser-Werkzeuge (Circle Crop, Größenänderung, die Komprimierungsvorschau) funktionieren weiter, sie brauchten das Netzwerk nie.
    • Komprimierungs-Download fällt auf das Vorschau-Blob im Browser zurück (etwas weniger effiziente Kodierung, aber funktionsfähig).
    • Hintergrund entfernen fällt auf das ISNet-WebAssembly-Modell zurück und funktioniert ohne jede ausgehende Anfrage.

Wenn die Werkzeuge offline funktionierten (die cloud-gestützten leicht abgeschwächt, die reinen Browser-Werkzeuge identisch), hat per Definition kein Server dein Bild gesehen.

Was wir sehen, und was nicht

Auf den clientseitigen Pfaden sehen wir nichts von deinem Bild. Es gibt keine Anfrage zum Ansehen, keinen Cache zum Speichern, keine Protokollzeile zum Durchsuchen.

Auf den serverseitigen Pfaden:

  • Der Komprimierungs- und PDF-Dienst sieht die Bildbytes für die Dauer der Kodierung (typisch ein paar hundert Millisekunden), behält einen inhaltsadressierten Cache-Eintrag für die Cache-TTL, und das war’s. Der Cache ist nicht nach Nutzer, IP, Dateiname oder einer Kennung indexiert, die wir nutzen könnten, um “deine” Bilder zu finden. Wir protokollieren keine Bildinhalte. Der Kodierdienst wird von denselben zwei Mandanten geteilt, die v1 vor der Umstellung bediente, mit CORS, Ratenbegrenzungen und HMAC-signierten kanonischen URLs pro Mandant.
  • Hintergrund entfernen und die anderen KI-Pfade sehen das Bild für die Dauer des Zwischen-Uploads und des Modellaufrufs (typisch ein paar Sekunden), danach wird die zwischengelagerte Kopie durch eine R2-Lebenszyklusregel gelöscht. Das BiRefNet-Modell läuft innerhalb von Cloudflares eigener Infrastruktur, nicht auf einer externen API im Stil von remove.bg / fal.ai / Replicate.

Auf jedem Pfad erfasst unser Analyseanbieter (Cloudflare Web Analytics) aggregierte Seitenaufrufdaten. URL, Land, Browserfamilie, Core Web Vitals. Keine Cookies, keine dauerhaften Kennungen, nichts, das an eine Person gebunden ist.

Bei Werkzeugen, die bei der ersten Nutzung ein WebAssembly-Modul herunterladen (der HEIC-Decoder, das ISNet-ONNX-Modell), sieht unser Hosting-Anbieter, dass jemand das Modul abgerufen hat, genauso wie er sieht, dass sie die CSS-Datei abrufen. Das Modul selbst enthält keine Information über dein Bild.

Das vollständige Datenverzeichnis steht in unserer Datenschutzerklärung.

Der Technologie-Stack

Für die Neugierigen:

  • Astro, der Generator für statische Seiten. Jede Seite wird als reines HTML mit progressiv verbesserten JavaScript-”Inseln” ausgeliefert, nur dort, wo interaktive Werkzeuge leben.
  • Reines CSS mit benutzerdefinierten Eigenschaften, kein Tailwind, kein CSS-in-JS. Das gesamte Designsystem ist eine einzige tokens.css-Datei.
  • canvas.toBlob / <canvas>. JPEG-, PNG-, WebP-, AVIF-Kodierung (browserunterstützt) in den reinen Browser-Werkzeugen, und die gesamte Zuschneide- und Größenänderungsarbeit.
  • Cropper.js, die Interaktionsschicht für das Zuschnittrechteck.
  • ONNX Runtime Web, führt die ISNet-WebAssembly-Ausweichlösung für Hintergrund entfernen aus.
  • Cloudflare Pages, hostet den statischen Build, liefert ihn vom Edge aus.
  • Cloudflare Workers + R2 + cf.image.segment (BiRefNet), die Standard-Pipeline für Hintergrund entfernen.
  • Fastify + sharp 0.34 + libvips 8.17 auf Node 24, der Komprimierungs- und PDF-Dienst unter api.roundcut.com.br, auf einem Hostinger-VPS in Deutschland.
  • Cloudflare Web Analytics, aggregierte, cookie-lose Seitenaufrufzählung.

Browser-Unterstützung

Jedes Werkzeug funktioniert in der aktuellen und der vorherigen Version von Chrome, Firefox, Safari und Edge, auf dem Desktop und mobil. Die Seite nutzt progressive Verbesserung: Wo ein Browser eine neuere API unterstützt (z. B. showSaveFilePicker, OffscreenCanvas), nutzen wir sie, wo nicht, fallen wir auf das ältere Äquivalent zurück. Es gibt keine “Dein Browser wird nicht unterstützt”-Wand.

Die einzigen harten Voraussetzungen sind JavaScript (für jedes Werkzeug) und eine Netzwerkverbindung (nur bei einem cloud-gestützten Werkzeug auf seinem Standardpfad, die reinen Browser-Werkzeuge laufen nach dem ersten Seitenaufruf vollständig offline).

Fragen

Etwas, das wir nicht abgedeckt haben? Schreib an support@roundcut.app. Technische Fragen sind willkommen.