Carica un file su un convertitore basato su server e accadono tre cose. Il tuo file viaggia attraverso la rete verso un indirizzo IP che non controlli. Un processo su quel server lo decodifica. Poi, a seconda della politica di conservazione del sito, il file rimane su disco da pochi minuti a per sempre.
Fai la stessa cosa in una scheda del browser e il file non lascia mai la RAM della tua macchina. Il decoder viene eseguito all'interno di un sandbox WebAssembly che il motore del browser applica. La rete non viene mai toccata.
Questa non è una differenza di politica. È una differenza architetturale. Un convertitore basato su server può promettere di eliminare i tuoi file; uno basato su browser non può divulgarli perché non li riceve mai in primo luogo.
L'architettura
Quattro livelli rendono possibile la conversione lato client:
Livello 1: Accesso ai file
Quando trascini un file in una scheda del browser, il DragEvent o <input type="file"> fornisce a JavaScript un oggetto File. Un File non è il contenuto del file. È un riferimento: un nome, una dimensione, un tipo MIME e un metodo (file.arrayBuffer()) che legge i byte dal disco alla memoria su richiesta.
Finché quel metodo non viene chiamato, zero byte si sono mossi. Il file rimane sul tuo file system. Il selettore file del browser è una finestra di dialogo a livello di sistema operativo; la pagina web vede solo l'oggetto File che l'utente ha esplicitamente selezionato.
Livello 2: Rilevamento del formato
I primi byte di qualsiasi file identificano il suo formato in modo affidabile. Un JPEG inizia con FF D8 FF. Un PNG inizia con 89 50 4E 47. Un file HEIC contiene una box ftyp con un brand heic o heif all'offset 8.
Leggere l'intestazione di un file (i primi 32 byte, tipicamente) è sufficiente per confermare cosa sia realmente, indipendentemente dall'estensione. Questo controllo viene eseguito prima che qualsiasi decoder tocchi i dati dei pixel. Se l'intestazione non corrisponde, il file viene rifiutato immediatamente. Nessuna CPU sprecata, nessun messaggio di errore confuso a metà decodifica.
Livello 3: Decodifica
I byte grezzi diventano pixel attraverso un decoder. Quale decoder dipende dal formato:
- JPEG, PNG, WebP, BMP: il browser fornisce decoder nativi per questi.
createImageBitmap()passa i byte compressi al codec della piattaforma (Windows Imaging Component su Windows, Core Graphics su macOS, Skia su Linux/ChromeOS) e restituisce dati pixel grezzi. Questo percorso è veloce, accelerato via hardware dove il sistema operativo lo supporta e non richiede codice aggiuntivo. - HEIC: nessun browser tranne Safari fornisce un decoder HEIC nativo. Il nostro convertitore include libheif, una libreria C, compilata in WebAssembly. Il binario
.wasm(~1,2 MB compresso) viene scaricato una volta e messo in cache. Decodifica i file HEIF/HEIC in pixel RGB grezzi interamente all'interno del sandbox WASM. - PDF: PDF.js (il renderer PDF di Mozilla) renderizza ogni pagina su un canvas alla risoluzione richiesta. Nessun rendering lato server. Il PDF non lascia mai il browser.
Ogni decoder legge dalla memoria e scrive in memoria. Nessuno apre socket. Il sandbox WASM in particolare non può effettuare richieste di rete: il browser non espone API di rete ai moduli WebAssembly. Anche se il codice C chiamasse socket(), il sandbox lo intercetterebbe.
Livello 4: Codifica
I pixel grezzi vanno nel contesto 2D di un elemento <canvas>. canvas.toBlob() o canvas.toDataURL() chiama l'encoder integrato del browser per l'output JPG, PNG o WebP. L'encoder è codice nativo della piattaforma: lo stesso percorso di codice che il tuo sistema operativo usa per salvare gli screenshot.
L'output è un Blob, un buffer di byte in memoria. Viene passato a un link di download o impacchettato in un archivio ZIP costruito in JavaScript. In nessun momento un singolo byte tocca un socket di rete.
Cosa applica il browser
Le pagine web vengono eseguite all'interno di un sandbox che il browser mantiene a livello di motore. Non è un accordo di cortesia. È imposto dall'isolamento dei processi:
Processo di rendering: il motore JavaScript, il DOM e il runtime WASM vivono in un processo isolato senza accesso diretto al file system o alla rete. Comunica con il mondo esterno tramite IPC verso il processo del browser.
Isolamento dei siti: i browser moderni mettono ogni origine nel proprio processo di rendering. I tuoi file su file-convert-factory.org sono invisibili al JavaScript in esecuzione su qualsiasi altro dominio.
Sandbox WASM: i moduli WebAssembly vedono un buffer di memoria lineare piatto e nient'altro. Nessuna API del file system, nessun fetch a meno che non sia esplicitamente importato da JavaScript, nessun accesso al DOM o ad altre API del browser. Il peggio che un modulo WASM compromesso potrebbe fare è corrompere la propria memoria e far crashare la scheda.
Un convertitore basato su server viene eseguito come processo privilegiato sul sistema operativo del server. Può leggere e scrivere su disco, aprire connessioni di rete e generare processi figli. Il modello di sicurezza dipende dalla competenza e dalle intenzioni dell'operatore del server. Il sandbox del browser dipende solo dalla correttezza del motore del browser, e i sandbox dei browser sono tra i confini di sicurezza più rigorosamente verificati nel software.
Cosa promettono (e non promettono) i convertitori basati su server
I convertitori basati su server non sono intrinsecamente malevoli. Molti sono gestiti da team ben intenzionati. Il problema è strutturale:
- Il passaggio di caricamento è una copia. Il tuo file ora esiste in due posti. Tu controlli una copia. Qualcun altro controlla l'altra.
- L'eliminazione è una promessa. «Eliminiamo i file dopo 24 ore» significa fidarsi della riga di log, del cron job, del sistema di backup e di ogni dipendente con accesso al server. Niente di tutto questo è verificabile dall'esterno.
- I metadati viaggiano con il file. I dati EXIF della tua foto (coordinate GPS, numero di serie della fotocamera, timestamp) fanno parte dei byte del file. Se il file viene caricato, i metadati vengono caricati. La nostra guida alla privacy EXIF descrive esattamente cosa contengono e come rimuoverli. In breve: ogni convertitore su questo sito rimuove i metadati perché decodifica i pixel e li ricodifica, scartando tutto ciò che non è dato immagine.
- HTTPS protegge il tubo, non il punto di arrivo. TLS crittografa il caricamento in transito. Non fa nulla per ciò che accade al file dopo l'arrivo.
La garanzia di privacy di un convertitore basato su browser è più ristretta ma più forte. Dice: i tuoi file non lasciano il tuo dispositivo perché non esiste un percorso di codice per farlo. Questo è verificabile. Apri la scheda Rete negli Strumenti per sviluppatori mentre converti un file. Vedrai il binario WASM caricarsi una volta, poi nulla. Zero byte caricati. Nessuna richiesta a /api/convert. Nessun traffico WebSocket. La conversione avviene interamente all'interno del processo di rendering.
Verificalo tu stesso
Non devi credere a nessuno sulla parola. Apri Chrome DevTools (F12), passa alla scheda Rete e converti un file su qualsiasi pagina strumento. L'unica attività di rete che vedrai:
- HTML, CSS e JavaScript della pagina: caricati una volta alla prima visita.
- Il binario WASM (per i convertitori HEIC): caricato una volta, memorizzato nella cache successivamente.
- Richieste di analisi (se non le hai bloccate).
Nessun dato del file lascia il browser. Il Content-Length di ogni richiesta è misurato in kilobyte, non in megabyte. Questo è verificabile indipendentemente da chiunque sappia aprire DevTools.
Lo stesso non si può dire per un servizio basato su server. Carichi il file, ottieni un risultato e ti fidi che il server lo abbia eliminato.
Strumenti correlati
Ogni convertitore su questo sito segue questa architettura. La pipeline (rilascia, convalida, decodifica, codifica, scarica) viene eseguita in modo identico su tutti i 23 strumenti:
- HEIC in JPG · HEIC in PNG · HEIC in WebP
- JPG in PNG · JPG in WebP · JPG in ICO
- PNG in JPG · PNG in WebP · PNG in ICO
- WebP in JPG · WebP in PNG · WebP in ICO
- BMP in JPG · BMP in PNG · BMP in WebP · BMP in ICO
- PDF in JPG · PDF in PNG · PDF in WebP
- Immagine in testo (OCR): stessa architettura lato client, esegue Tesseract in WASM
Per i dettagli tecnici dietro il sandbox WASM, consulta la nostra spiegazione di WebAssembly. Per un approfondimento su quali metadati contengono le tue foto, la guida alla privacy EXIF spiega come leggerli e rimuoverli byte per byte.
