Come funziona RoundCut

La risposta breve

RoundCut usa un’architettura ibrida: la maggior parte degli strumenti gira interamente nel tuo browser senza alcun caricamento, e un piccolo gruppo instrada una singola richiesta di rete attraverso la nostra infrastruttura quando il browser non riesce a eguagliare la qualità, sempre con un fallback lato client invisibile. Ti diciamo su quale percorso sei, in ogni strumento e su questa pagina.

La tabella qui sotto è rappresentativa, non esaustiva (nuovi strumenti escono regolarmente). Mostra un esempio di ciascun tipo di percorso:

Strumento di esempio	Dove avviene il lavoro
Ritaglio circolare (solo browser)	100% nel tuo browser, Canvas API. Nessun caricamento, funziona offline.
Anteprima di compressione (solo browser)	100% nel tuo browser, canvas.toBlob. Nessun caricamento. Lo slider resta istantaneo.
Download finale della compressione (tocca il server)	Un giro di andata e ritorno al nostro servizio su api.roundcut.com.br (Fastify, sharp e libvips su un VPS in Germania), con un fallback nel browser.
Rimozione dello sfondo (tocca il server)	Un giro di andata e ritorno a un Cloudflare Worker che esegue BiRefNet sulle GPU edge di Cloudflare, con un fallback WebAssembly nel tuo browser quando il cloud non è raggiungibile.

Ritaglio, ridimensionamento, conversione di formato (tranne la codifica AVIF) e l’anteprima di compressione girano tutti completamente nel tuo browser. La rimozione dello sfondo, il download della compressione, l’upscaling con AI, la codifica AVIF e il PDF con più immagini instradano ciascuno una singola richiesta e ricadono sul browser quando il cloud non è raggiungibile.

Puoi verificare le affermazioni sul lato client in circa 30 secondi: apri DevTools → Network, svuota il log, poi usa uno strumento solo-browser come il ritaglio circolare o lo slider dell’anteprima di compressione, vedrai uscire dalla pagina zero richieste che trasportano i byte della tua immagine. Per gli strumenti che toccano il server vedrai esattamente un caricamento per operazione, verso endpoint dichiarati.

Perché ibrido

La maggior parte degli strumenti per immagini online si colloca a un estremo: carica-tutto-su-un-server (aspetti i giri di andata e ritorno e l’operatore tiene il tuo file) oppure tutto-nel-browser (paghi in qualità e velocità sui passaggi di codifica e di AI). Nessuno dei due estremi vince ovunque.

Abbiamo scelto il lato client dove i browser sono già eccellenti, l’elemento <canvas> gestisce ritaglio, rotazione, ridimensionamento e la codifica dell’anteprima con perdita in JPG/WebP, e il lato server dove il browser perde ancora in modo misurabile:

• La compressione delle immagini, sul download finale. sharp e libvips 8.17 lato server producono file del 10-15% più piccoli a parità di byte rispetto agli encoder del browser con la stessa qualità visiva, e danno accesso alla regolazione di velocità e croma per AVIF e all’output JPEG XL che il browser non espone. Lo slider e l’anteprima girano comunque nel tuo browser, così l’iterazione resta istantanea, solo il tocco su “Download” passa per il nostro servizio.
• La rimozione dello sfondo con AI e l’upscaling con AI, sul percorso predefinito. I modelli (BiRefNet per la segmentazione, la super-risoluzione per l’ingrandimento) hanno bisogno di una GPU reale per finire in pochi secondi. I fallback nel browser funzionano ma sono più lenti e producono un risultato visibilmente più grezzo su capelli, pelo e bordi sottili.
• La codifica AVIF, sulla conversione. L’encoder AVIF nel browser è lento su alcuni dispositivi, perciò l’output AVIF instrada una richiesta al Worker di compressione, con una codifica nel browser sul thread principale come fallback.

Il costo che accettiamo per stare sul lato server su quei percorsi è un giro di andata e ritorno per operazione. Il costo che evitiamo restando sul lato client ovunque altro è la tariffa del giro di andata e ritorno sulle parti del flusso che iterano più rapidamente.

La pipeline, passo dopo passo

1. Selezioni un file

Tramite il selettore di file, il trascinamento o l’incolla, il browser passa a JavaScript un oggetto File. JavaScript legge i byte usando FileReader o Blob.arrayBuffer(). In nessun momento di questo passaggio il file viene inviato in rete, indipendentemente dallo strumento che stai usando.

2. Il browser decodifica l’immagine

I browser moderni decodificano nativamente JPG, PNG, WebP, GIF e AVIF. Usiamo createImageBitmap() per trasformare i byte grezzi in una bitmap su cui la GPU può lavorare, fuori dal thread principale. Per l’HEIC sui browser che non lo decodificano nativamente, ricadiamo su un decoder WebAssembly che gira localmente nel tuo browser.

3. Lo strumento fa la sua parte, è qui che i percorsi divergono

• Strumenti solo browser (ritaglio, ridimensionamento, conversione di formato in PNG/JPEG/WebP, l’anteprima di compressione). Una trasformazione di pixel con Canvas 2D o un codec WebAssembly ricodifica la bitmap localmente. Il risultato è pronto senza alcun caricamento. Cropper.js gestisce la cornice di ritaglio interattiva per gli strumenti di ritaglio, e canvas.toBlob gestisce la ricodifica dell’anteprima. Interamente nel tuo browser.
• Compressione, download. Quando tocchi “Download”, l’immagine viene inviata una volta a api.roundcut.com.br (un servizio Fastify che gira su un VPS in Germania gestito da Hostinger, Node 24 con sharp 0.34 e libvips 8.17, le stesse librerie C che Squoosh usa sul suo percorso server). Viene ricodificata con gli stessi parametri impostati nell’anteprima, e i byte vengono restituiti in streaming al tuo browser. Il servizio mantiene una cache isolata per tenant e indirizzata per contenuto (un hash dei byte di input e dei parametri) con un limite di 500 MB, così riscaricare la stessa immagine con le stesse impostazioni ripropone i byte memorizzati, la cache non è indicizzata per te, IP o nome file. Se il servizio non è raggiungibile, lo strumento ricade sul blob dell’anteprima nel browser.
• Rimozione dello sfondo, percorso cloud predefinito. L’immagine viene caricata una volta su un Cloudflare Worker, messa in staging in un bucket R2 privato, elaborata dalla trasformazione cf.image.segment di Cloudflare che esegue il modello BiRefNet sulle GPU edge di Cloudflare, e il ritaglio viene restituito in streaming. L’oggetto R2 in staging viene eliminato entro un’ora da una regola del ciclo di vita di R2, qualunque sia l’esito. Una foto tipica finisce in 1-3 secondi. I limiti giornalieri per IP e i 5 MB di caricamento mantengono il piano gratuito sostenibile.
• Altri strumenti basati sul cloud (upscaling con AI, codifica AVIF, PDF con più immagini) seguono la stessa forma: una richiesta a un’infrastruttura dichiarata (un’API cloud per le immagini per la super-risoluzione, il Worker di compressione per la codifica AVIF, il nostro servizio VPS per il PDF con più immagini), risultato restituito in streaming, e un fallback trasparente nel browser se quella richiesta fallisce.
• Fallback WebAssembly. Se il percorso cloud pertinente non è raggiungibile (la rete cade, sei dietro un firewall rigido, la quota giornaliera è esaurita, o il file supera il limite del cloud), lo strumento passa in modo trasparente a un modello o codec locale che gira nel tuo browser, per esempio il modello di rimozione dello sfondo ISNet tramite ONNX Runtime Web con WebAssembly. La prima esecuzione scarica il modello ed è più lenta, le esecuzioni successive sono più veloci. Nessun caricamento su questi percorsi di fallback, puoi verificarlo in DevTools.

4. Scarichi il risultato

La bitmap di output viene codificata in un Blob, avvolta in un object URL e offerta alla finestra di salvataggio file standard del tuo browser. Il file compare sul tuo disco.

Come verificarlo da solo

Scegli quello che preferisci:

Metodo 1. Osserva la scheda Network

1. Apri RoundCut in una scheda nuova e apri DevTools → Network.
2. Usa uno strumento solo browser, il ritaglio circolare o lo slider dell’anteprima di compressione. Vedrai richieste solo per HTML/CSS/JS/font, più i moduli WebAssembly pertinenti al primo uso. Nessuna richiesta trasporterà i byte della tua immagine.
3. Ora usa uno strumento che tocca il server, Compressione → Download oppure Rimozione dello sfondo. Vedrai esattamente un POST che trasporta la tua immagine, e una risposta che torna con il risultato. Passa il puntatore su una richiesta per vedere dimensione e tempi.

La colonna “Initiator” ti dice quale script ha attivato ogni richiesta, e la colonna “Type” ti dice cosa è stato inviato. Non nascondiamo nessuna delle due.

Metodo 2. Usa gli strumenti offline

1. Carica una pagina di uno strumento di RoundCut. Usa la rimozione dello sfondo una volta su un’immagine piccola, così il modello ISNet nel browser viene memorizzato.
2. Apri DevTools → Network → spunta Offline (o spegni il Wi-Fi).
3. Ricarica la pagina, le risorse statiche sono memorizzate, quindi si carica comunque.
4. Prova gli strumenti:
   • Gli strumenti solo browser (ritaglio circolare, ridimensionamento, l’anteprima di compressione) continuano a funzionare, non hanno mai avuto bisogno della rete.
   • Il download della compressione ricade sul blob dell’anteprima nel browser (codifica leggermente meno efficiente, ma funzionale).
   • La rimozione dello sfondo ricade sul modello WebAssembly ISNet e funziona senza alcuna richiesta in uscita.

Se gli strumenti hanno funzionato offline (quelli basati sul cloud leggermente degradati, quelli solo browser identici), per definizione nessun server ha visto la tua immagine.

Cosa vediamo, e cosa no

Sui percorsi lato client, non vediamo nulla della tua immagine. Non c’è una richiesta da guardare, nessuna cache in cui conservarla, nessuna riga di log da cercare.

Sui percorsi lato server:

• Il servizio di compressione e PDF vede i byte dell’immagine per la durata della codifica (di solito qualche centinaio di millisecondi), conserva una voce di cache indirizzata per contenuto per il TTL della cache, e basta. La cache non è indicizzata per utente, IP, nome file o qualsiasi identificatore che potremmo usare per trovare le “tue” immagini. Non registriamo il contenuto delle immagini. Il servizio di codifica è condiviso tra gli stessi due tenant che v1 serviva prima del passaggio, con CORS per tenant, limiti di velocità e URL canonici firmati con HMAC.
• La rimozione dello sfondo e gli altri percorsi AI vedono l’immagine per la durata del caricamento in staging e della chiamata al modello (di solito qualche secondo), dopodiché la copia in staging viene eliminata da una regola del ciclo di vita di R2. Il modello BiRefNet gira dentro l’infrastruttura di Cloudflare, non su un’API esterna in stile remove.bg / fal.ai / Replicate.

Su ogni percorso, il nostro fornitore di analisi (Cloudflare Web Analytics) registra dati aggregati di visualizzazione delle pagine. URL, paese, famiglia di browser, Core Web Vitals. Nessun cookie, nessun identificatore persistente, niente legato a una persona.

Per gli strumenti che scaricano un modulo WebAssembly al primo uso (il decoder HEIC, il modello ONNX ISNet), il nostro fornitore di hosting vede che qualcuno ha scaricato il modulo, allo stesso modo in cui vede scaricare il file CSS. Il modulo in sé non contiene alcuna informazione sulla tua immagine.

L’inventario completo dei dati è nella nostra informativa sulla privacy.

Lo stack tecnologico

Per i curiosi:

• Astro, il generatore di siti statici. Ogni pagina esce come semplice HTML con “isole” JavaScript a miglioramento progressivo solo dove vivono gli strumenti interattivi.
• CSS vanilla con proprietà personalizzate, niente Tailwind, niente CSS-in-JS. L’intero design system è un singolo file tokens.css.
• canvas.toBlob / <canvas>. Codifica JPEG, PNG, WebP, AVIF (supportati dal browser) negli strumenti solo browser, e tutto il lavoro di ritaglio e ridimensionamento.
• Cropper.js, il livello di interazione del rettangolo di ritaglio.
• ONNX Runtime Web, esegue il fallback WebAssembly ISNet per la rimozione dello sfondo.
• Cloudflare Pages, ospita la build statica, la serve dall’edge.
• Cloudflare Workers, R2 e cf.image.segment (BiRefNet), la pipeline predefinita di rimozione dello sfondo.
• Fastify con sharp 0.34 e libvips 8.17 su Node 24, il servizio di compressione e PDF su api.roundcut.com.br, su un VPS Hostinger in Germania.
• Cloudflare Web Analytics, conteggi aggregati delle visualizzazioni di pagina, senza cookie.

Supporto dei browser

Ogni strumento funziona sulla versione attuale e su quella precedente di Chrome, Firefox, Safari ed Edge, desktop e mobile. Il sito usa il miglioramento progressivo: dove un browser supporta un’API più recente (per esempio showSaveFilePicker, OffscreenCanvas) la usiamo, dove non la supporta ricadiamo sull’equivalente più vecchio. Non c’è alcun muro “il tuo browser non è supportato”.

Gli unici requisiti rigidi sono JavaScript (per qualsiasi strumento) e una connessione di rete (solo quando usi uno strumento basato sul cloud sul suo percorso predefinito, gli strumenti solo browser girano completamente offline dopo il primo caricamento della pagina).

Domande

Qualcosa che non abbiamo trattato? Scrivi a support@roundcut.app. Le domande tecniche sono benvenute.