Convert Website Images to WebP Locally With ImageMagick and PowerShell

When you have a website with hundreds of JPG or PNG images and want to move them all to WebP, the obvious move is a plugin or script that converts them right on the server — on upload, or via a cron job. On a host with unlimited resources, fine. On shared hosting with CPU limits (which is most budget plans), converting dozens or hundreds of images at once is exactly the kind of job that trips a "resource limit reached" and can slow the rest of your site down while it runs.

The alternative I've actually used and that works well: do the conversion on your own computer with ImageMagick and PowerShell, then upload only the finished WebP files. The server never runs a single conversion process — it just serves static files, which is what it's best at.

Why it matters where the conversion happens

On shared hosting, image processing is one of the heaviest short bursts of CPU a site can trigger: decoding the original, recalculating compression, and re-encoding into another format are all expensive operations. The host runs a resource monitor that kills processes that exceed their quota — that's not a bug, it's a protection so one account doesn't degrade performance for everyone else on the same box. If that conversion happens to run during your site's traffic peak (say, right after deploying new content), the slowdown or brief outage lands on your actual visitors.

Converting locally removes that risk entirely: the heavy lifting happens on your own machine, which has no quota to respect, and the host only ever receives the already-optimized result. If it is only a handful of images, converting them to WebP in the browser saves you installing ImageMagick at all.

Installing ImageMagick on Windows

Grab the installer from imagemagick.org (the Q16-HDRI build for Windows). Current versions ship with WebP support built in, so nothing else is required beyond PowerShell, which is already part of Windows.

To confirm it installed correctly, open PowerShell and run:

magick -version

The command I use: convert a whole folder in one go

To convert every JPG and PNG in a folder (subfolders included) to WebP at quality 82, without touching the originals:

magick mogrify -path .\webp -format webp -quality 82 .\images\*.jpg
magick mogrify -path .\webp -format webp -quality 82 .\images\*.png

mogrify is ImageMagick's command built for processing multiple files at once; -path tells it where to write the output (so the originals stay untouched in their own folder), and -format webp sets the output format regardless of input type.

If you also need to walk subfolders while keeping their structure, this pure PowerShell version does the job and preserves relative paths:

Get-ChildItem -Path .\images -Recurse -Include *.jpg,*.jpeg,*.png | ForEach-Object {
    $relative = $_.FullName.Substring((Resolve-Path .\images).Path.Length)
    $target   = Join-Path .\webp ($relative -replace '\.(jpg|jpeg|png)$', '.webp')
    New-Item -ItemType Directory -Force -Path (Split-Path $target) | Out-Null
    magick $_.FullName -quality 82 $target
}

What quality to use

With -quality between 75 and 85, the visual difference from the original JPG or PNG is practically invisible on screen, and the file is typically 25-35% smaller than the equivalent JPG (often more against a photographic PNG). Below 70, artifacts start showing in smooth gradients, the same way they do in JPG.

If an image has transparency, or it's a flat-color graphic like a logo or icon, add -define webp:lossless=true so edges don't lose sharpness.

Only convert what's new, not the whole site every time

Once you've already got a webp folder generated and only added a handful of new photos, re-running the conversion on everything is wasted effort. This version compares timestamps and only converts files that are newer than their WebP counterpart (or that don't have one yet):

Get-ChildItem -Path .\images -Recurse -Include *.jpg,*.png | ForEach-Object {
    $target = Join-Path .\webp ($_.BaseName + ".webp")
    if (-not (Test-Path $target) -or $_.LastWriteTime -gt (Get-Item $target).LastWriteTime) {
        magick $_.FullName -quality 82 $target
    }
}

That turns the process into something you can rerun every time you add new photos, taking seconds, without reprocessing what's already done.

Getting the result onto your host

Once the WebP files are generated locally, upload them over FTP/SFTP or your control panel's file manager, just like any other static file. The server doesn't run anything — it only serves them, which is essentially free in CPU terms compared to the conversion itself.

One detail worth handling at the same time: if your site serves images with plain <img> tags, you'll need to point them to the new .webp files, or use a <picture> block with the JPG/PNG as a fallback for the small remaining share of browsers without WebP support (a negligible minority today, but the fallback costs one line of HTML).

Works the same on WordPress, PrestaShop, or any CMS

This method doesn't depend on the platform: you convert images locally, then upload them to your CMS's media library the same way you would any other file.

• WordPress: upload the generated .webp files from Media → Add New, or replace files directly in wp-content/uploads/ over (S)FTP if you want to keep the same URLs.
• PrestaShop: product images live under /img/p/ and /img/c/; upload the WebP versions there or through the back office, depending on how your theme serves them.
• Any other CMS (Joomla, Drupal, a static site): the process is the same — convert on your own machine, then upload the result through whatever channel you'd normally use for a new image.

Back up before every conversion. If you're going to replace the originals (rather than just adding the .webp files alongside them), save a copy of the media folder or wp-content/uploads/ before overwriting anything. A naming or path mistake in a large batch is easy to make and, without a backup, hard to undo.

When this isn't necessary

If your hosting doesn't enforce aggressive CPU limits (a VPS or your own dedicated server, for example), or you already use a CDN or image-optimization service that transforms images on the fly at no cost to your origin server, this manual step is optional — still useful for full control over quality, but not urgent. Where it actually matters is budget shared hosting, which is the setting I've tested it on, and where the CPU savings show up directly in whether your site keeps responding while you convert a hundred photos.

FAQ

← Back to the blog · Compress images online