Convertitore di immagini in batch gratuito

Converti più immagini in una volta sola tra PNG, JPG e WebP. Regola la qualità, confronta le dimensioni dei file e scarica tutto all'istante.

I tuoi dati non lasciano mai il tuo dispositivo
Rilascia qui le immagini o clicca per sfogliare (JPEG, PNG, WebP, GIF, BMP, TIFF)

Elaborazione in corso…

Informazioni sulla conversione di formato immagine

Ogni formato immagine ha il suo utilizzo. Il PNG è senza perdita, ideale per la grafica; il JPG è perfetto per le foto e offre file più piccoli; il WebP propone una compressione moderna con qualità elevata. La conversione in batch fa risparmiare tempo per trattare più file.

JPEG (1992): il formato per le fotografie

Il Joint Photographic Experts Group fu formato nel novembre 1986 a Parsippany, New Jersey, con membri tratti da ISO TC97 SC2/WG8 e dal gruppo CCITT SGVIII. Sei anni di lavoro di comitato dopo, il testo della CCITT Recommendation T.81 fu approvato il 18 settembre 1992, con testo identico pubblicato come ISO/IEC International Standard 10918-1 nel 1994. Quella pubblicazione a due documenti è il momento in cui JPEG diventò il formato fotografico del mondo. Il nucleo matematico è la trasformata coseno discreta applicata a blocchi di pixel 8×8: ogni blocco viene scomposto in una somma di onde coseno, le componenti ad alta frequenza a cui la visione umana è meno sensibile vengono quantizzate più aggressivamente di quelle a bassa frequenza che l'occhio nota per prime. Il cursore "qualità" rivolto all'utente è esattamente questo: un moltiplicatore sulla tabella di quantizzazione. Qualità più alta significa divisori più piccoli, più precisione, file più grandi. Qualità più bassa significa più zeri dopo la quantizzazione, migliore codifica entropica e un file più piccolo al costo di blocchi visibili e artefatti di ringing. JPEG è lossy per design: non c'è impostazione di qualità a cui un round-trip JPEG sia matematicamente identico al suo input. Per fotografie di scene naturali (volti, paesaggi, cibo, qualunque cosa con gradienti morbidi e tono continuo) questo è irrilevante; la perdita vive sotto la soglia di sensibilità della visione umana e il file è una frazione della dimensione che un formato lossless produrrebbe. Per grafica con bordi netti, testo, line art o grandi aree di colore piatto, JPEG è la scelta sbagliata: lo stesso DCT spalma i bordi netti con artefatti di ringing ("mosquito noise") e confini a blocchi tra le celle 8×8.

PNG (ottobre 1996 / gennaio 1997): il formato grafico lossless

PNG (Portable Network Graphics) was developed in 1994 by an informal group outside W3C as a deliberate response to two problems with the existing options: GIF's patent encumbrance (covered below) and TIFF's complexity. The specification was approved as a W3C Recommendation on 1 October 1996, and on 15 January 1997 it was released by the IETF as RFC 2083. A second edition incorporating errata became a W3C Recommendation on 10 November 2003; a third edition adding APNG, HDR support and Exif handling was published on 24 June 2025. PNG is lossless, every encoded byte is recoverable. Internally, a PNG file is a sequence of typed chunks (IHDR header, IDAT compressed data, IEND end-of-file marker, plus optional ancillary chunks for colour profile, transparency, gamma and metadata). Pixel data is preprocessed by one of five row filters (None, Sub, Up, Average, Paeth) chosen per scanline to maximise compressibility, then run through DEFLATE, the same algorithm used in zip files and gzip. PNG supports four colour modes: greyscale, greyscale with alpha, indexed colour (palette of up to 256 entries, what people call PNG-8), and truecolor RGB (PNG-24) with optional 8-bit alpha (PNG-32). The alpha channel supports 256 levels of partial transparency per pixel, which is what makes it possible to anti-alias the edges of icons against any background without the dreaded "white halo" PNG-8 indexed transparency used to produce. PNG was designed as a web format and an archival format simultaneously, and that dual role is why it remains the default for screenshots, logos, line art, charts, and any image where pixel-perfect reproduction matters more than file size.

GIF (15 giugno 1987): il superstite delle animazioni e la saga dei brevetti

Steve Wilhite, capo ingegnere di CompuServe, introdusse GIF il 15 giugno 1987 per risolvere un problema specifico: come condividere immagini a colori attraverso i lenti modem del servizio online di CompuServe senza che i file divorassero la franchigia mensile dell'utente. La sua squadra scelse l'algoritmo di compressione Lempel-Ziv-Welch (LZW) e limitò la palette di colori a 256 voci. Ciò che CompuServe non sapeva nel 1987 era che LZW era stato brevettato dalla Sperry Corporation (poi Unisys) nel 1985. La questione del brevetto esplose alla luce del sole alla fine del 1994. Unisys annunciò nel 1995 che avrebbe chiesto royalty sul software che usava l'algoritmo, incluso GIF, TIFF e PDF, a tassi di circa 0,45-0,65% del fatturato. La comunità open-source del web rispose con due azioni parallele: la campagna "Burn All GIFs" e la progettazione di PNG, esplicitamente per essere un sostituto di GIF libero da brevetti. Il brevetto Unisys USA è scaduto nel giugno 2003; i brevetti corrispondenti in altre giurisdizioni sono scaduti entro il 2004. Entro il 2004, GIF era libero da brevetti per la prima volta nella sua storia. GIF è sopravvissuto grazie a una caratteristica che PNG (originariamente) non aveva: l'animazione. Supporta una sequenza di frame con tempi di ritardo per frame e un indice di palette trasparente, rendendolo la lingua franca delle reaction image in loop e dei banner web. La palette a 256 colori è una vera limitazione per le foto e la trasparenza a 1 bit produce bordi brutti quando si sovrappone su uno sfondo colorato, ma per brevi animazioni in loop di contenuti in stile cartone GIF vince ancora per supporto universale.

BMP (maggio 1990) e TIFF (autunno 1986): i resistenti legacy

BMP (Bitmap, chiamato anche Windows Device Independent Bitmap) fu integrato in Windows 3.0, rilasciato il 22 maggio 1990, dove divenne lo standard per la memorizzazione bitmap nell'ambiente grafico Windows. È essenzialmente non compresso: l'array di pixel grezzo, opzionalmente allineato per riga su un confine di 4 byte, con un piccolo header all'inizio. Un BMP a 24 bit di 1920×1080 è circa 6,2 MB; la stessa immagine come JPEG di qualità-85 potrebbe essere 200 KB. Il ruolo di BMP nel 2026 è essenzialmente quello di formato di interscambio legacy e il formato che gli screenshot di Windows storicamente usavano. TIFF (Tagged Image File Format) fu pubblicato per la prima volta da Aldus Corporation nell'autunno 1986 (Revision 3.0); la Revision 6.0 nel giugno 1992 aggiunse il colore CMYK e YCbCr e JPEG-in-TIFF. Adobe acquisì Aldus nel 1994 e ne detiene ora il copyright. TIFF è unico nell'essere un formato contenitore piuttosto che un singolo schema di codifica: un singolo file TIFF può contenere immagini multiple (TIFF multipagina, comune per fax e capitoli di libro scansionati), usare uno qualunque di diversi metodi di compressione (nessuna, LZW, ZIP, JPEG, CCITT Group 3/4 per fax) e memorizzare metadati essenzialmente arbitrari attraverso la sua struttura a campi taggati. Questa flessibilità rende TIFF il default per i workflow di prestampa, scansione e archivio documentale; non viene praticamente mai usato per immagini web. La sua presenza nell'elenco di input è per gli utenti che convertono sorgenti destinati alla stampa o scansionati in formati adatti al web.

WebP (30 settembre 2010): il formato moderno per il web

Google annunciò WebP il 30 settembre 2010 come nuovo formato aperto per grafica a colori veri compressa lossy sul web, producendo file più piccoli di JPEG a qualità comparabile. Il formato è basato sulla codifica dei keyframe del codec video VP8, che Google aveva acquisito con l'acquisto di On2 Technologies. Inizialmente WebP era solo lossy. Il 18 novembre 2011, Google annunciò una modalità di compressione lossless e il supporto alla trasparenza sia in modalità lossless sia lossy; libwebp 0.2.0 raggiunse un'implementazione lossless stabile il 16 agosto 2012. Per la documentazione di Google: le immagini WebP lossless sono circa il 26% più piccole delle stesse immagini in PNG, e le immagini WebP lossy sono il 25-34% più piccole di JPEG comparabili a qualità SSIM equivalente. Queste riduzioni non sono magia: vengono da un design del codec fondamentalmente più recente (codifica intra-frame predittiva, codifica entropica aritmetica moderna, trasformazioni di colore più intelligenti) rispetto alle baseline dei primi anni '90 contro cui JPEG e PNG furono progettati. Il supporto del browser è stato una costruzione lenta: Chrome 17 nel febbraio 2012 (lossy), Chrome 23 nel novembre 2012 (lossless). Apple ha resistito per la maggior parte di un decennio e ha finalmente aggiunto il supporto WebP in Safari 14, distribuito con iOS 14 e macOS 11 Big Sur nel settembre 2020. Quel settembre 2020 è il momento in cui WebP è diventato praticamente utilizzabile come formato web primario senza un fallback JPEG per gli utenti iPhone. La copertura oggi è circa il 97% del traffico globale: WebP non è più un formato "moderno" con riserve, è un default.

Oltre WebP: AVIF (feb 2019), HEIC (2017), JPEG XL (2018-)

AVIF v1.0.0 fu rilasciato il 19 febbraio 2019 dall'Alliance for Open Media (AOMedia, un consorzio di Google, Netflix, Microsoft, Mozilla, Cisco, Intel, Amazon, Apple). È il profilo a immagine fissa del codec video AV1, costruito sul contenitore HEIF, ed è attualmente il formato d'immagine ampiamente distribuito che comprime meglio: a qualità visiva equivalente, i file AVIF sono tipicamente il 50% più piccoli di JPEG e il 20-30% più piccoli di WebP. Il supporto del browser è arrivato in tre ondate: Chrome 85 (agosto 2020), Firefox 93 (ottobre 2021), Safari con iOS 16 (settembre 2022) e macOS Ventura (ottobre 2022). HEIC è il formato di default di iPhone dal iOS 11 nel 2017: il contenitore HEIF con immagini compresse HEVC, formalmente ISO/IEC 23008-12. La compressione è eccellente (tipicamente il 50% più piccola di JPEG) ma HEVC è gravato da brevetti, motivo per cui Chrome, Firefox e Edge non-Apple rifiutano di decodificare HEIC nativamente. JPEG XL (ISO/IEC 18181, 2022) è il formato di nicchia tecnicamente eccellente: può ricomprimere senza perdita JPEG esistenti per renderli ~20% più piccoli, supporta HDR, gamma ampia, animazione e decodifica progressiva, ed è libero da brevetti. Chrome ha rimosso il suo flag sperimentale il 31 ottobre 2022 (la "decisione di Halloween"); Apple ha distribuito Safari 17 nel settembre 2023 con JPEG XL nativo su macOS Sonoma, iOS 17 e visionOS. Il formato è supportato nativamente in Safari 17+, dietro un flag in Firefox e Chrome 145 (febbraio 2026), ma la distribuzione di default per il traffico generale resta in attesa. Questo convertitore non emette attualmente AVIF, HEIC o JPEG XL: sono elencati qui in modo che tu possa decidere se gestirli a monte.

Scegliere il formato di output giusto

La storia formato-per-formato sopra è un giro turistico. La domanda pratica è più breve: data una particolare immagine e un particolare uso, quale formato di output è corretto?

Cosa fa davvero il cursore della qualità

Il cursore della qualità va da 10 a 100 in passi di 5. Dietro quel singolo numero c'è una relazione sorprendentemente non lineare tra qualità percepita e dimensione del file. Per JPEG, il consenso fra l'ingegneria del trattamento di immagini è che la qualità 75-85 è il punto dolce. A qualità 80, la dimensione del file scende del 70-90% rispetto a una sorgente non compressa con differenza visiva impercettibile alle distanze normali di visione su schermo. La caduta tra qualità 80 e 85 è ripida: un'immagine di test rappresentativa potrebbe passare da 3,7 MB a qualità 80 a 6 MB a qualità 85, quasi un raddoppio per nessun miglioramento visibile su uno schermo di telefono o laptop. La qualità 75 è dove gli artefatti iniziano a diventare rilevabili a un'ispezione ravvicinata di dettagli ad alta frequenza (bordi del testo, texture fini). La qualità 90 e oltre è per JPEG d'archivio dove la dimensione del file è irrilevante. Il default 80 si trova all'estremo inferiore del punto dolce, appropriato per l'ottimizzazione web batch, dove l'obiettivo è spedire il minor numero possibile di dati mantenendo immagini che sembrano accettabili. Per WebP, il default toBlob('image/webp') dell'API canvas è qualità 0,80; WebP a qualità 70 è generalmente visivamente pulito quanto JPEG a qualità 80. Per PNG, "qualità" è un termine improprio: PNG è sempre lossless sui dati pixel. Il cursore in questo strumento non ha effetto quando PNG è selezionato come formato di output. La lezione cruciale per l'elaborazione batch: una singola impostazione di qualità è raramente corretta per ogni immagine in un batch misto. Una cartella di 50 foto scattate con la stessa fotocamera nella stessa illuminazione probabilmente può essere salvata tutta a JPEG qualità 80 senza perdita. Una cartella che mescola screenshot, foto, line art e loghi non può: un "convert all to JPG-80" a un pulsante trasformerà gli screenshot in mosquito-noise illeggibile. Dividi l'input in batch separati quando il contenuto varia.

Lossy contro lossless: la distinzione più importante

Un encoder lossless garantisce che l'output decodificato sia bit per bit identico all'input codificato. PNG è lossless. WebP-lossless è lossless. TIFF (nelle sue modalità lossless) è lossless. Il compromesso è la dimensione del file: gli encoder lossless non possono sfruttare differenze percettive impercettibili e devono preservare tutto. Una fotografia di 1920×1080 come PNG lossless potrebbe essere 5 MB; la stessa foto come JPEG-qualità-85 è 200 KB. Il PNG è bit-perfetto; il JPEG è visivamente equivalente. Un encoder lossy scarta informazioni che il sistema visivo umano è meno probabile che noti: dettaglio ad alta frequenza, fine variazione di chroma in colori saturi, la quarta cifra significativa di ogni gradiente. JPEG, WebP lossy e AVIF lossy fanno tutti questo. Le implicazioni per un convertitore batch sono concrete: lossless a lossless (PNG a PNG, o PNG a WebP-lossless) è genuinamente lossless attraverso qualsiasi numero di conversioni; lossy a lossy alla stessa qualità (JPEG-85 a JPEG-85) non è lossless: ogni ricodifica applica un altro passaggio di quantizzazione, ripeti 10 volte e il risultato è visibilmente degradato; lossy a lossless (JPEG a PNG) congela gli artefatti esistenti in posizione ma non li ridegrada; lossless a lossy introduce compressione lossy al momento della conversione e non c'è modo di recuperare il dettaglio scartato in seguito. Gli utenti spesso rieseguono una conversione aspettandosi che sia un no-op. Fuori dal caso lossless-a-lossless, non lo è.

EXIF, IPTC, XMP: e perché questo strumento li elimina

I file JPEG e HEIC da fotocamere e telefoni portano un blocco EXIF: metadati Exchangeable Image File Format incorporati nell'header dell'immagine. EXIF include modello della fotocamera, obiettivo, impostazioni di esposizione, data e ora, versione del software, e in modo più conseguente le coordinate GPS di dove è stata scattata la foto (se i servizi di localizzazione erano attivi al momento dello scatto). I metadati IPTC aggiungono didascalia, byline, copyright e parole chiave. XMP, originariamente di Adobe, è un superset basato su XML che subordina i formati più vecchi ed è ciò che Lightroom e Photoshop usano. Le implicazioni sulla privacy sono significative. Una foto scattata su un iPhone con la posizione abilitata incorpora coordinate GPS accurate entro pochi metri. Condividerla su un forum, in un allegato email o tramite un blog personale può rivelare l'indirizzo di casa del fotografo, la scuola del suo bambino, il suo posto di lavoro, il suo percorso di trekking. Le grandi piattaforme social (Facebook, Instagram, Twitter/X) eliminano EXIF al caricamento prima di servire l'immagine ad altri utenti, ma loro stesse leggono e conservano i metadati originali. Forum più piccoli, blog WordPress, Discord, client di posta e trasferimenti diretti di file lasciano l'EXIF intatto. La ricodifica attraverso l'API canvas (il motore che questo strumento usa) scarta tutti i metadati EXIF, IPTC e XMP per default. L'output è un'immagine pulita senza provenienza incorporata: una caratteristica di privacy, e un effetto collaterale della pipeline canvas (il canvas memorizza solo dati pixel; non ha nozione di metadati da preservare). Gli utenti che vogliono preservare i metadati (fotografi che archiviano dati di esposizione, workflow di contenuto dove il copyright deve viaggiare con il file) hanno bisogno di uno strumento diverso: tipicamente convert di ImageMagick o una libreria dedicata consapevole di EXIF. Questo convertitore taglia nell'altro modo: è metadata-stripping per design, che è esattamente ciò che un utente attento alla privacy vuole quando manda immagini a un forum dove non vuole che le sue coordinate GPS lo seguano.

Sfondi trasparenti: la scelta PNG-a-JPEG

PNG supporta un canale alfa per pixel: ogni pixel ha un'opacità da 0 (completamente trasparente) a 255 (completamente opaco). JPEG non ha canale alfa. Convertire un PNG con trasparenza in JPEG forza una scelta: cosa dovrebbero diventare i pixel trasparenti? Il default dell'API canvas è di comporre contro nero trasparente, quindi il JPEG risultante risolve i pixel trasparenti in nero opaco. Un logo su sfondo trasparente convertito da PNG a JPEG esce con angoli neri attorno al logo: praticamente mai ciò che l'utente voleva. La mitigazione è riempire il canvas con un colore di sfondo scelto (il bianco è il default tipico) prima di disegnare l'immagine sopra. Gli utenti che hanno bisogno di preservare la trasparenza dovrebbero scegliere PNG o WebP come formato di output. WebP supporta la trasparenza sia in modalità lossless sia lossy, il che lo rende la scelta moderna quando la sorgente ha trasparenza e la destinazione deve essere efficiente: un PNG di 50 KB con sfondo trasparente potrebbe diventare un WebP lossy di 12 KB con sfondo trasparente preservando il canale alfa.

Come gira la conversione nel tuo browser

L'affermazione "tutto gira nel tuo browser" si basa su tre Web Platform API che solo recentemente sono diventate abbastanza potenti da rendere un convertitore di immagini batch un prodotto credibile lato client. API FileReader e Blob: quando trascini i file nella zona di caricamento, ogni File è una sottoclasse di Blob che espone o readAsDataURL() (callback più vecchio) o file.arrayBuffer() (basato su Promise). Per le immagini specificamente, il percorso più semplice è costruire un Blob URL con URL.createObjectURL(file) e assegnarlo a un nuovo elemento Image, lasciando che il decoder di immagini integrato del browser gestisca JPEG, PNG, GIF, WebP e BMP nativamente. L'API Canvas: una volta caricata un'Image, la conversione è una danza in due passi: disegna con ctx.drawImage(img, 0, 0), poi rileggi il canvas con canvas.toBlob(callback, type, quality). Il parametro type è una stringa MIME ('image/png', 'image/jpeg', 'image/webp'); il parametro quality è un numero tra 0 e 1 per i formati lossy. OffscreenCanvas e Web Worker: per batch grandi, fare tutto il lavoro canvas sul thread principale blocca l'UI. La soluzione moderna è OffscreenCanvas, che espone le operazioni canvas in un contesto worker ed è esso stesso trasferibile a un Web Worker tramite postMessage senza copiare. Il worker esegue la pipeline decodifica-rasterizza-codifica in un thread separato, mantenendo la pagina reattiva. Insieme queste API fanno girare un batch di 50 file in pochi secondi senza bloccare lo scrolling o i click sui pulsanti. JSZip, una libreria pure-JavaScript con licenza MIT, gestisce il packaging ZIP finale interamente in memoria prima che si attivi la finestra di salvataggio del browser. Niente upload, niente zip server, niente file temporaneo su disco. Un decennio fa un convertitore di immagini batch che girava nel browser sarebbe stato una curiosità. Le prestazioni di WebAssembly, il parallelismo di OffscreenCanvas e la RAM moderna dei telefoni (6-12 GB) e i conteggi di core (6-8 CPU) hanno invertito quella foto. L'argomento privacy chiude il caso: i convertitori lato server richiedono il caricamento delle tue immagini su una macchina di terzi, e anche con una scrupolosa policy di cancellazione il caricamento stesso è un evento di rete che può essere registrato, intercettato o violato. Un convertitore solo browser non manda mai un byte.

Domande frequenti

Quali formati immagine sono supportati?

Il convertitore tratta la maggior parte dei formati comuni (JPG, PNG, GIF, WebP, BMP, TIFF) e converte in PNG, JPG o WebP.

Posso regolare la qualità per JPG e WebP?

Sì. Usa il cursore di qualità per regolare la compressione (0-100). Valori più alti danno una qualità migliore ma file più grandi.

Come scaricare più file?

Scegli «Scarica tutto in ZIP» per raggruppare tutte le immagini convertite in un unico archivio ZIP, comodo da scaricare e conservare.

Perché il limite è di 50 file per batch?

È un soffitto di memoria. Ogni immagine deve essere decodificata in RAM come dati pixel grezzi prima che il canvas possa ricodificarla. Una foto iPhone di 12 megapixel decodifica a circa 36 MB di dati pixel (12 milioni di pixel × 3 byte RGB, o 4 byte RGBA). 50 di queste insieme sono 1,8 GB di memoria di lavoro. La maggior parte dei laptop le gestisce comodamente; i telefoni più vecchi no. Il cap di 50 file mantiene la pagina prevedibile attraverso i dispositivi. Per batch più grandi, esegui lo strumento a turni: diciamo 50 file, scarica, pulisci, lascia altri 50.

C'è un limite di dimensione per file?

Nessun cap rigido: il limite è la memoria disponibile del tuo dispositivo. Una singola immagine da 50 MP decodifica a circa 150 MB di dati pixel, che funziona su un desktop ma farà fatica su un telefono più vecchio. Come regola generale, file sotto 10 MB convertono fluidamente essenzialmente su qualsiasi dispositivo; file sopra 50 MB rallenteranno o falliranno su mobile di fascia bassa. Se una conversione si blocca, ricarica la pagina e prova il file in un batch più piccolo.

Il convertitore elimina i metadati EXIF?

Sì, per design. La pipeline di ricodifica canvas memorizza solo dati pixel, quindi i blocchi di metadati EXIF, IPTC e XMP (modello fotocamera, impostazioni di esposizione, coordinate GPS, tag di copyright, cronologia delle modifiche) non sopravvivono al round-trip. L'output è un'immagine pulita senza provenienza incorporata, che è una vittoria per la privacy quando condividi foto su forum o contatti email dove non vuoi che le coordinate GPS ti seguano. Se hai bisogno che i metadati siano preservati (fotografi che archiviano dati di esposizione, workflow di contenuto che richiedono tag di copyright), questo è lo strumento sbagliato: usa convert di ImageMagick o una libreria dedicata consapevole di EXIF che preserva esplicitamente i metadati.

Cosa succede agli sfondi trasparenti quando converto PNG in JPG?

JPEG non ha canale alfa, quindi i pixel trasparenti nel PNG sorgente devono diventare un colore opaco nell'output JPEG. Il comportamento di default del canvas è di comporre contro uno sfondo colorato (tipicamente bianco). Un logo su uno sfondo PNG trasparente convertito in JPEG perderà la trasparenza e prenderà il riempimento di sfondo. Se la trasparenza conta, scegli PNG o WebP come formato di output: entrambi preservano l'alfa. WebP-lossy preserva la trasparenza con dimensioni di file drammaticamente più piccole di PNG ed è la scelta moderna per la grafica web trasparente.

Le mie immagini vengono caricate da qualche parte?

No. Ogni passaggio (selezione del file, decodifica, ricodifica canvas, packaging ZIP, download) gira interamente nel tuo browser tramite JavaScript. Non c'è elaborazione lato server. Puoi verificarlo aprendo il pannello Network di DevTools del tuo browser mentre converti: non ci sono richieste in uscita che trasportano dati di immagine. La pagina è sicura per screenshot sensibili, scansioni di documenti, foto personali con metadati di posizione, o qualunque altra cosa che non vorresti vedere copiata sul disco di uno sconosciuto.

Strumenti correlati

PDF → HTML

Converti PDF in HTML all'istante.

Codificatore Base64

Codifica immagini in Base64.

Testo → CSV

Converti dati in formato CSV.