← Torna al blog

Come convertire JPG in WebP offline su Windows

Converti le foto JPG in WebP localmente su Windows 11, misura la variazione reale delle dimensioni e pubblica immagini più veloci per il sito web con un fallback JPG sicuro.

Di LocalFlux Editorial Team

Immagini Guida
LocalFlux mostra tre conversioni completate da JPG a WebP per immagini destinate a siti web e la riduzione misurata delle dimensioni.
In questa pagina
  1. La versione breve
  2. Perché la conversione da JPG a WebP può aiutare un sito web
  3. I file utilizzati per questo test
  4. Passaggio 1: aggiungi i file JPG
  5. Passaggio 2: scegli la conversione diretta o il modello per siti web
  6. Passaggio 3: controlla le opzioni effettive
  7. Passaggio 4: converti e controlla le copie
  8. Risultati misurati
  9. Pubblica il WebP correttamente
  10. Metadati e privacy restano aspetti distinti
  11. Conversione in batch senza perdere il controllo
  12. Quando JPG può essere ancora la scelta migliore
  13. Domande frequenti
  14. Crea il WebP, misuralo e poi pubblicalo

Le fotografie di grandi dimensioni possono far sembrare lenta una pagina web molto prima che il resto del design abbia la possibilità di fare la differenza. Convertire un JPG in WebP può ridurre il numero di byte delle immagini scaricati da un visitatore, ma la domanda utile non è se WebP sia moderno. È se il tuo specifico file WebP sia più piccolo, abbia ancora un aspetto accettabile e venga distribuito correttamente dal sito web.

Con LocalFlux su Windows 11, aggiungi uno o più file JPG, scegli WebP e convertili senza inviare le immagini a un servizio online. Apri Risultati rapidi, quindi scegli Prepara per un sito web.

LocalFlux mostra tre conversioni completate da JPG a WebP con la riduzione misurata delle dimensioni.

Le schermate dell’interfaccia sono state aggiornate nell’ottobre 2026 con una build ricostruita dal codice documentato di LocalFlux 1.0.10.0. Le misurazioni e i download storici mantengono l’ambito dei test originali. Registri delle acquisizioni: 1

Il batch di immagini per siti web sottoposto a test è stato completato localmente. I tre file WebP erano più piccoli del 66%, 67% e 75% rispetto agli input JPG mostrati in LocalFlux. Queste misurazioni descrivono questo insieme di file di test, non costituiscono una garanzia universale per WebP.

Ideale per: JPG fotografici utilizzati in landing page, immagini di articoli, pagine di prodotti, portfolio e altri flussi di pubblicazione sul web in cui il peso del download è importante.

Conserva gli originali JPG: questo flusso WebP aggiunge un’altra codifica con perdita. Non può ripristinare i dettagli già rimossi dalla compressione JPG e il file sorgente resta la copia più sicura per la modifica e il fallback.

Verifica del 13 ottobre 2026: i 30 output per siti web della versione ricostruita 1.0.10.0 corrispondono agli hash dei WebP web storici. La tabella e i download della conversione diretta restano il confronto di 1.0.7; quegli output diretti sono stati decodificati e rimisurati, non rigenerati. Le tre immagini mantengono le dimensioni. La presenza di EXIF non dimostra che ogni campo sia stato conservato. Verifica dei file

La versione breve

  1. Apri LocalFlux su Windows 11.
  2. Aggiungi uno o più file .jpg o .jpeg.
  3. Mantieni selezionato Convertire e scegli WebP come output.
  4. Apri Risultati rapidi, quindi scegli Prepara per un sito web.
  5. Conferma le impostazioni di ridimensionamento e qualità prima di eseguire un batch di grandi dimensioni.
  6. Seleziona Convertire.
  7. Apri i nuovi file WebP, confronta le aree ricche di dettagli con i JPG e misura i byte effettivi.
  8. Pubblica il WebP con dimensioni esplicite e un fallback JPG quando i tuoi requisiti di compatibilità lo richiedono.

Scarica LocalFlux dal Microsoft Store oppure consulta i formati e i percorsi attualmente supportati prima di iniziare.

Perché la conversione da JPG a WebP può aiutare un sito web

Una richiesta di immagine consuma larghezza di banda e compete con il resto della pagina. Un numero inferiore di byte può ridurre il tempo di trasferimento, soprattutto su un telefono o una rete più lenti. Ciò non significa che cambiare l’estensione migliori automaticamente le prestazioni: contano tutti il risultato codificato, le dimensioni visualizzate, la memorizzazione nella cache, le varianti responsive, la priorità della richiesta e la posizione nella pagina.

Le indicazioni di Google sui formati delle immagini consigliano formati moderni come WebP o AVIF quando producono un rapporto qualità-dimensioni adeguato, mantenendo al contempo un percorso basato su un formato meno recente quando necessario. Analogamente, le indicazioni di Google Search sulla SEO delle immagini sottolineano l’importanza di immagini di alta qualità e della velocità, anziché considerare un singolo formato una scorciatoia per il posizionamento.

JPG e WebP con perdita sono entrambi formati di distribuzione per contenuti fotografici. L’opportunità pratica offerta da WebP è creare una copia di distribuzione più piccola con una qualità visiva accettabile. Non consiste nel rendere nuovamente nitido un JPG di bassa qualità. Una volta che il JPG ha eliminato le texture fini o introdotto aloni attorno a un bordo, la transcodifica può soltanto codificare i pixel rimasti.

Inoltre, distingui tre operazioni che vengono spesso confuse:

OperazioneAzione pertinente
Cambiare il formato di distribuzione al browserConvertire JPG in WebP
Ridurre dimensioni in pixel eccessiveRidimensionare alla dimensione massima effettivamente visualizzata dal layout
Rimuovere metadati relativi a posizione, dispositivo, autore o dataUtilizzare un flusso di rimozione dei metadati supportato e verificare la copia

Il modello Prepara per un sito web combina in modo prudente le prime due operazioni, ma non abilita Condividi in sicurezza e non promette un numero di byte specifico.

I file utilizzati per questo test

Questa procedura guidata utilizza tre JPG utilizzabili legalmente nella cartella C:\tmp\LocalFluxJpgToWebPBlog:

La fotografia mette alla prova texture e gradienti naturali. L’acquisizione dell’interfaccia mette alla prova testo piccolo e bordi netti, sui quali una seconda codifica con perdita può essere più facile da notare. L’immagine promozionale mette alla prova ampie aree piatte e gradienti delicati. Tutte e tre sono opache, quindi questo articolo non ripete i consigli sulla trasparenza e sulla grafica presenti nella guida alla conversione da PNG a WebP.

I tre file JPG utilizzabili legalmente impiegati per il test di conversione.

Gli input comprendono una fotografia, contenuti UI nitidi e un’immagine hero orizzontale in stile sito web. Il percorso di lavoro neutro e i contenuti multimediali controllati nel repository evitano di esporre un account Windows personale o una risorsa di un cliente.

Illustrazione storica: l’interfaccia inglese fa parte dell’immagine di prova, non dei passaggi attuali. I valori «KB» usano unità binarie (KiB).

Passaggio 1: aggiungi i file JPG

Trascina i file JPG su LocalFlux oppure seleziona Aggiungi file. Prima della conversione, verifica che ogni riga in coda riporti JPG → WebP. Un batch utilizza un’unica scelta di output e un unico insieme di impostazioni visive, quindi separa i file in esecuzioni diverse se richiedono dimensioni di distribuzione o livelli di qualità differenti.

Tre file JPG in attesa in LocalFlux con WebP selezionato.

WebP viene selezionato una sola volta per il batch. LocalFlux scriverà nuove copie accanto ai file sorgente anziché sostituire i file JPG.

Per una raccolta di immagini che non conosci, inizia con un sottoinsieme rappresentativo anziché con un intero archivio. Includi una fotografia ricca di dettagli, un volto se la raccolta contiene ritratti, un gradiente e un’immagine con testo o un logo. Un’impostazione di qualità che appare adeguata sul fogliame potrebbe essere troppo morbida per le scritte.

Passaggio 2: scegli la conversione diretta o il modello per siti web

Esistono due punti di partenza utili.

La conversione diretta cambia il formato in WebP lasciando le dimensioni ai valori originali e utilizzando il comportamento predefinito dell’encoder per la qualità. Isola il cambio di formato e costituisce un utile riferimento di base.

Apri Risultati rapidi, quindi scegli Prepara per un sito web. La versione ricostruita 1.0.10.0 applica queste impostazioni:

Prepara per un sito web

Il risultato selezionato appare nel pannello delle opzioni. Condividi in sicurezza è disattivato; i metadati vengono conservati.

La regola dei 1920 pixel è un limite massimo, non un comando per estendere ogni immagine fino a 1920 pixel. Nessuno dei tre file di test superava il limite e l’immagine hero da 1920 × 1080 vi corrispondeva già esattamente. Tutti e tre gli output del modello per siti web hanno quindi mantenuto le dimensioni dei JPG. Il risparmio aggiuntivo rispetto alla conversione diretta è derivato dall’impostazione della qualità, non dal ridimensionamento.

Passaggio 3: controlla le opzioni effettive

Apri Opzioni ed espandi Regolazioni avanzate. Conferma i valori anziché presumere che il nome di un modello rappresenti sempre la stessa implementazione in ogni versione futura.

Le opzioni mostrano il riepilogo per il sito web e le regolazioni avanzate espanse.

Il riepilogo indica WebP, massimo 1920 × 1920 e qualità 82%. Il preset Web mantiene le proporzioni e non ingrandisce mai. Scorri nel pannello per controllare le altre impostazioni.

La qualità non è una scala universale tra formati. Non è garantito che un valore di 82 in un encoder WebP corrisponda alla qualità 82 in un altro strumento, né tale valore promette uno specifico numero di byte. Consideralo un punto di partenza riproducibile all’interno di questo flusso di lavoro. Confronta il risultato anziché scegliere un numero basandoti sulle convinzioni diffuse.

Se il tuo layout visualizza un’immagine a soli 800 pixel di larghezza, un file da 1920 pixel può comunque essere inutilmente grande. Ridimensionalo alla massima dimensione di rendering effettivamente necessaria oppure crea varianti responsive per diverse larghezze di layout. Viceversa, non ridurre un file sorgente al di sotto delle dimensioni necessarie per un display ad alta densità soltanto per ottenere un confronto più favorevole delle dimensioni del file.

Passaggio 4: converti e controlla le copie

Seleziona Converti 3 file. LocalFlux crea file .webp con nomi distinti e mantiene i JPG al loro posto. Al termine, controlla l’output in un browser e con uno zoom del 100%. Osserva attentamente:

Non giudicare soltanto da un provino a contatto. Alle dimensioni di visualizzazione riportate sotto, le coppie appaiono simili. In scala nativa, i WebP per siti web sono visibilmente un po’ più morbidi nelle aree più impegnative, ricche di dettagli fini e di elementi dell’interfaccia, perché sono copie con perdita di seconda generazione. Questo compromesso può essere ragionevole per la distribuzione, ma il JPG dovrebbe rimanere il file sorgente o di fallback.

Gli input JPG accanto agli output WebP del modello per siti web con le dimensioni misurate.

Tutti e tre i WebP per siti web hanno mantenuto le rispettive dimensioni e sono risultati sostanzialmente più piccoli in questo test. Il confronto non dichiara un’identità a livello di pixel né una conversione senza perdita.

Risultati misurati

Le esecuzioni della conversione diretta e del modello per siti web hanno utilizzato gli stessi tre file sorgente e la stessa build pacchettizzata di LocalFlux 1.0.7.

File di testInput JPGWebP direttoVariazione direttaWebP per sito webVariazione per sito webDimensioni
Foto di montagna274.913 byte169.980 byte38,2% più piccolo92.448 byte66,4% più piccolo1440 × 960
UI di LocalFlux126.755 byte64.626 byte49,0% più piccolo42.334 byte66,6% più piccolo1320 × 940
Immagine hero di LocalFlux67.861 byte28.880 byte57,4% più piccolo17.216 byte74,6% più piccolo1920 × 1080
Totale469.529 byte263.486 byte43,9% più piccolo151.998 byte67,6% più piccoloNon applicabile

Il materiale fornito include l’esatto JPG della montagna, il WebP diretto della montagna e il WebP per sito web della montagna; il JPG della UI, il WebP diretto della UI e il WebP per sito web della UI; nonché il JPG dell’immagine hero, il WebP diretto dell’immagine hero e il WebP per sito web dell’immagine hero utilizzati per queste misurazioni.

Nel complesso, il batch del modello per siti web era più piccolo del 42,3% rispetto al batch WebP diretto. Ciò non dimostra che la qualità 82 sia corretta per ogni sito. Dimostra perché una decisione sulla qualità orientata ai siti web può essere importante quanto la scelta di WebP.

Lo strumento di ispezione incluso ha segnalato tutti gli output come file WebP validi, opachi e statici, con le dimensioni previste. Il JPG della montagna esponeva un profilo EXIF e anche entrambi i relativi WebP, diretto e del modello per siti web, esponevano un profilo EXIF. Gli altri due input e output non esponevano alcun profilo. Gli hash SHA-256 dei file sorgente sono rimasti invariati dopo entrambe le esecuzioni.

Questi risultati sono volutamente specifici per i file di test. Un JPG già ottimizzato può produrre un risparmio minore, nessun risparmio o persino un WebP più grande con un’impostazione di qualità elevata. Misura l’output e scarta una conversione che non migliora la risorsa di distribuzione abbastanza da giustificare un’altra copia.

Leggi le percentuali nel loro contesto

Una percentuale è utile soltanto quando il denominatore è visibile. Risparmiare il 70% su una miniatura minuscola può eliminare meno byte che risparmiare il 20% su una grande immagine hero. Per questo batch, il modello per siti web ha eliminato in totale 317.531 byte: circa 310 KiB prima della compressione HTTP e dell’overhead di trasporto. La fotografia della montagna ha contribuito alla maggior parte di questa riduzione assoluta perché era il file sorgente più grande.

Distingui inoltre le dimensioni del file dalle dimensioni di rendering. Un browser può visualizzare un file da 1920 × 1080 a una larghezza di 600 pixel CSS, ma il download riguarda comunque l’intera risorsa codificata, a meno che la selezione responsive non fornisca un candidato più piccolo. Al contrario, il CSS che estende un file da 600 pixel fino a 1200 pixel non può ricreare i dettagli mancanti. La pipeline di pubblicazione richiede sia una codifica appropriata sia dimensioni intrinseche appropriate.

Per un controllo ripetibile delle prestazioni, registra i byte dell’originale e dell’output, conferma l’URL di produzione, quindi verifica la pagina su una connessione mobile rappresentativa. Evita di dichiarare un miglioramento fisso dei tempi di caricamento sulla base di un confronto locale delle dimensioni dei file: latenza, stato della cache, posizione del server, priorità delle richieste e risorse concorrenti influiscono tutti sull’esperienza di un visitatore.

Pubblica il WebP correttamente

Generare un file WebP è soltanto metà del lavoro. La pagina necessita comunque di markup valido, dimensioni di layout stabili, testo alternativo utile e una politica di fallback adeguata.

L’elemento HTML <picture> consente al browser di scegliere un file sorgente supportato mantenendo un fallback <img>:

<picture>
  <source srcset="mountain-photo.webp" type="image/webp">
  <img
    src="mountain-photo.jpg"
    width="1440"
    height="960"
    alt="Prato di montagna al tramonto"
    decoding="async">
</picture>

Qui <img> offre un’alternativa di formato quando nessuna <source> è adatta. Un errore nella richiesta WebP, come HTTP 404, non avvia automaticamente un nuovo tentativo con JPG. Verifica entrambi gli URL separatamente.

Inserisci per primo il file sorgente WebP preferito e mantieni l’elemento <img> per ultimo. Gli attributi width e height forniscono al browser le proporzioni dell’immagine prima che la scarichi, aiutando il layout a riservare lo spazio corretto. Il CSS può comunque rendere responsive l’immagine visualizzata:

img {
  max-width: 100%;
  height: auto;
}

Se il design utilizza larghezze significativamente diverse, crea varianti reali e usa srcset e sizes affinché un viewport stretto non scarichi un file delle dimensioni previste per desktop. Non inventare un srcset che associ più descrittori di larghezza alla stessa immagine sottostante.

Per le immagini sotto la piega, l’attributo nativo loading="lazy" può evitare lavoro finché l’immagine non si avvicina al viewport. Non caricare in modalità lazy la probabile immagine hero sopra la piega o quella che determina il Largest Contentful Paint. Le indicazioni di web.dev sul caricamento lazy a livello di browser consigliano di caricare immediatamente le immagini visibili nel primo viewport, perché posticiparle può ritardare il rendering anziché migliorarlo.

Infine, configura il server o l’host statico affinché invii WebP come image/webp, utilizza intestazioni di cache a lunga durata per le risorse con versione e verifica la risposta di produzione negli strumenti per sviluppatori del browser. Un file codificato perfettamente ma con un tipo MIME errato, un URL non funzionante o nessuna politica di cache non rappresenta un’ottimizzazione completata.

Prima di considerare pubblicata l’immagine, verifica questo breve elenco di controllo per la produzione:

Metadati e privacy restano aspetti distinti

La conversione in WebP non rende automaticamente anonima una fotografia. L’immagine della montagna contenente dati EXIF ha mantenuto un profilo EXIF in entrambi i flussi di lavoro sottoposti a test perché Condividi in sicurezza era disattivato. Ciò è coerente con il riepilogo visibile del modello per siti web: i metadati vengono mantenuti.

Se un’immagine verrà pubblicata e le informazioni incorporate su posizione, dispositivo, autore o data costituiscono un problema, utilizza un flusso supportato per la rimozione dei metadati e controlla successivamente l’output. Leggi La conversione dei file rimuove i metadati EXIF? per comprendere la differenza tra cambiare formato e rimuovere i metadati privati.

La rimozione dei metadati può ridurre leggermente il numero di byte, ma la privacy dovrebbe essere una decisione di pubblicazione esplicita anziché un espediente nascosto per migliorare le prestazioni. Conserva tutti i metadati effettivamente richiesti dal tuo flusso legale, editoriale, di accessibilità o di gestione delle risorse.

Conversione in batch senza perdere il controllo

LocalFlux scrive un output per ogni riga pronta. Un file non riuscito o non valido dovrebbe essere esaminato singolarmente anziché presumere che ogni estensione .jpg identifichi un JPEG integro. Per un flusso di lavoro più ampio dedicato a una raccolta di immagini, consulta Come comprimere immagini in batch su Windows.

Quando JPG può essere ancora la scelta migliore

Continua a distribuire JPG quando è già abbastanza compatto, una destinazione richiesta non accetta WebP oppure un’altra copia WebP aggiunge complessità operativa senza una riduzione di byte significativa. Un fallback può essere utile anche per vecchie webview incorporate, client di posta elettronica, sistemi di acquisizione dei contenuti o strumenti a valle, anche quando gli attuali browser più diffusi supportano WebP.

Non convertire un JPG in WebP e poi di nuovo in JPG come ciclo di modifica. Le codifiche con perdita ripetute accumulano danni. Esegui le modifiche a partire dal miglior file sorgente disponibile e genera le risorse di distribuzione una sola volta, verso la fine della pipeline di pubblicazione.

Per loghi, icone, ritagli trasparenti e diagrammi nitidi, parti dal formato sorgente che preserva i bordi e il canale alfa necessari. La procedura guidata esistente da PNG a WebP tratta questo compito. Per una spiegazione più ampia su come aprire e convertire i file WebP, consulta la guida di sopravvivenza a WebP.

Domande frequenti

WebP rende sempre un JPG più piccolo?

No. È successo per tutte e tre le immagini sottoposte a test, ma il risultato dipende dal contenuto, dalla qualità del file sorgente, dalla qualità dell’output, dalle dimensioni, dai profili e dal comportamento dell’encoder. Confronta i byte effettivi.

La conversione da JPG a WebP migliora la qualità dell’immagine?

No. Un WebP con perdita può essere una copia di distribuzione efficiente, ma non può recuperare dettagli già eliminati dal JPG. Aggiunge un’altra codifica, quindi controlla i dettagli fini prima della pubblicazione.

Il modello per siti web ha ridimensionato questi file?

No. Tutti e tre gli input erano già pari o inferiori al limite di 1920 pixel per il lato lungo. Le dimensioni sono rimaste 1440 × 960, 1320 × 940 e 1920 × 1080.

La conversione rimuove i metadati EXIF?

Non darlo per scontato. Il JPG della montagna contenente dati EXIF ed entrambi gli output WebP sottoposti a test esponevano un profilo EXIF. La rimozione dei metadati era disattivata e deve essere gestita come un passaggio separato e verificato.

I JPG originali vengono sovrascritti?

No, non in questo flusso di lavoro. LocalFlux ha scritto nuove copie WebP accanto ai file sorgente e gli hash dei tre JPG dopo la conversione corrispondevano agli hash precedenti alla conversione.

Ogni sito web dovrebbe utilizzare un fallback JPG?

Non necessariamente. Gli attuali browser più diffusi supportano WebP, ma il tuo pubblico potrebbe includere webview meno recenti o sistemi diversi dai browser. Il modello <picture> offre un fallback semplice quando la tua politica di compatibilità lo richiede.

WebP è sufficiente per rendere veloce una pagina?

No. Utilizza immagini responsive di dimensioni appropriate, dimensioni esplicite, una memorizzazione nella cache efficace e una priorità di caricamento sensata. Il formato delle immagini è soltanto una parte delle prestazioni di distribuzione.

Crea il WebP, misuralo e poi pubblicalo

Il flusso di lavoro affidabile è semplice: conserva il JPG, crea localmente una copia WebP per la distribuzione, confronta il risultato in scala nativa e conferma che la pagina di produzione distribuisca la risorsa corretta. In questo test, il batch orientato ai siti web ha ridotto 469.529 byte di input a 151.998 byte senza ridimensionare alcuna immagine. Il risparmio misurato è una prova utile; gli originali conservati e un controllo sincero della qualità sono ciò che rende sicuro il flusso di lavoro.

Scarica LocalFlux dal Microsoft Store oppure consulta i formati e i percorsi supportati.