How to convert images to WebP (WordPress, manually, automatically)

Converting images to WebP comes down to preparing lighter file versions and correctly wiring them up everywhere the site actually uses them. In practice, this is not just a matter of changing the extension from JPG or PNG to .webp. You need to verify whether thumbnails, responsive images, CSS backgrounds, cache and any CDN still work after implementation. The biggest mistake is assuming that converting the files alone will automatically speed up the site without changing the way they are delivered. The implementation method depends primarily on where the images are loaded from: the WordPress library, the theme, the builder, CSS or an external source. For that reason, before starting the work, it is worth first identifying where the graphics actually appear and what is responsible for rendering them.

What converting to WebP means in practice

Converting to WebP in practice means generating .webp files from existing images and connecting them in the places where they are used on the site so that the layout, thumbnails or responsiveness do not break. The WebP file itself will not change much if the HTML, CSS or WordPress still point to the existing JPG or PNG addresses. That is why the scope of work includes not only exporting images, but also the way they are served.

On a typical site, graphics rarely appear only as a single file in the content. Usually, there are also intermediate versions, thumbnails, srcset variants and sometimes separate images for retina or for hero sections set as backgrounds. If these elements are not included in the implementation, part of the site will still load old files even though WebP has already been generated.

There are usually three operating models. The first is manual conversion, meaning preparing the files yourself and replacing the references. The second is automatic conversion in WordPress using a plugin or tool that creates WebP for media and intermediate sizes. The third is delivering WebP at the server or CDN level, where the user receives a lighter variant without manually editing the content.

Safe implementation means keeping the original JPG and PNG files and treating WebP as a parallel version rather than the only source. This makes it easier to roll back changes, recompress with different settings and resolve quality issues more effectively. This is especially important for graphics with text, transparency or fine details, where overly aggressive compression can reduce readability.

The benefit of WebP is usually straightforward: smaller files mean lower transfer and often faster image loading. However, this does not work the same for every file. The effect depends on the quality of the source image, the compression settings and whether the site has really started fetching the new variants instead of the old ones.

Current implementation context

Today, WebP is supported by default by most modern browsers, so it is usually implemented as the standard image delivery format on a site. This makes the business decision easier, but it does not mean the implementation itself becomes simple. You still need to determine how the given site creates and serves graphics.

In WordPress, the media library does not handle everything automatically for every image source. It works best where graphics are embedded in the usual way and pass through WordPress mechanisms. When files are located in the theme directory, are set in CSS, in a builder, in ACF fields or come from an external system, an additional handling layer is usually needed.

The scope of work increases with the number of places from which the site pulls graphics. You approach WebP differently on a simple blog than in an online store with a builder, sliders, product cards and custom sections. The mere presence of WebP files on the server does not yet mean that the user is actually downloading them.

Not every image should be treated in the same way. Photos usually cope well with lossy conversion, whereas graphics with transparency, thin lines or text require visual verification. SVG is most often left unchanged because it is a different type of asset and in many situations can be a better choice than raster.

In practice, problems usually emerge after implementation rather than during the conversion itself. The site may still serve old thumbnails, cache can return stale responses, and CSS may continue to point to old backgrounds. If, after the changes, you do not check in the browser which files are actually being fetched, it is easy to consider the job done even though nothing has changed in practice.

How the process works step by step

The process looks like this: first you identify where the site gets its images from, then you choose the conversion model, generate the WebP files, connect them in the places where they are used, and finally verify what actually reaches the browser. Skipping this order often ends up with you compressing files only, but not changing the way assets are delivered. This is a common reason why, after implementation, file sizes still look almost identical.

At the start, it is worth inventorying all image sources: the WordPress media library, post content, products, the builder, the theme directory, CSS and background images. If you miss even one source, part of the site will still load old JPG or PNG files. In practice, CSS backgrounds, sliders and builder modules cause the most problems, because they do not always rely on the same mechanisms as standard images in the content.

The second stage is choosing the implementation method. Manual conversion gives full control over quality and file naming, but it involves manually replacing addresses. Automatic conversion in WordPress is convenient within the media library, while the server-side or CDN model works well when you want to serve WebP without editing every post and template separately.

Before you start generating new files, it is a good idea to secure the originals and define clear quality criteria. Photos can usually be converted with lossy compression, but graphics with text, logos and PNGs with transparency are worth viewing live after the change. The safest approach is to keep WebP as a parallel variant, instead of overwriting the source without any way back.

The conversion process itself looks different depending on the environment. In WordPress, the tool should generate WebP not only for the original, but also for thumbnails and intermediate sizes, because these are what end up in srcset and on mobile views. With a manual approach, it is best to maintain a consistent directory structure and consistent naming so that the later replacement is easy to predict.

Once the files have been generated, they need to be properly connected to the site. This can be done by directly replacing URLs, using the picture element, or through server and CDN rules that serve the correct format according to the browser’s capabilities. The mere presence of .webp files on the server changes nothing if the HTML, CSS or rendering mechanism still points to the old assets.

In the end, validation remains. It is worth checking image quality, transparency handling, the correctness of thumbnails, and then clearing the WordPress, server and CDN cache. Only a test in the browser and in developer tools will show whether the site is actually fetching WebP, or merely appears to have been implemented correctly.

What to do to make the implementation work correctly

To make the implementation work correctly, you need to ensure three things: full image coverage, proper connection of the new variants, and clean cache after the changes. If any of these elements fails, the result will be incomplete or misleading.

In WordPress, first check whether the plugin or service generates WebP for all sizes used by the theme and plugins. The original from the media library is not enough, because on the front end thumbnails, responsive versions and images from srcset are usually loaded. After implementation, it is a good idea to regenerate thumbnails; otherwise some variants may not be created at all.

When replacing things manually, you need to go through the places that are easiest to miss. This is not only the content of posts, but also hero sections, sliders, product cards, images embedded in the builder, URLs in CSS and files in the theme directory. If these elements are not covered by the change, the site will run in mixed mode and it will be harder to assess the real gain.

Not every file should be converted according to one scheme. Very small images often do not bring a noticeable benefit, SVGs should usually remain in their own format, and PNGs with transparency need to be visually verified after conversion. The biggest benefits are usually delivered by large photos and graphics that are actually responsible for the site’s weight.

It is worth looking separately at intermediary mechanisms such as lazy load, cache, image optimisers and CDN. These layers can serve outdated files, modify headers or conflict with the plugin generating WebP. For this reason, after every change you should verify the server response, the HTML code and the assets actually fetched, rather than relying solely on the page preview in the admin panel.

When images come from external sources, are injected by script or are created dynamically, standard WordPress conversion often does not cover this scope. In such a situation, a separate approach may be needed: changing the rendering method, custom handling in the template, or delivering variants via the server or CDN. Most often, after implementation, problems appear such as missing CSS background replacement, incorrect srcset, double optimisation and cache serving older versions.

The most common problems and how to avoid them

The most common issues when converting to WebP concern situations where the files have been generated, but the site still loads the old JPG or PNG. This is usually because only the file format changes, while the way they are connected in HTML, CSS, the builder or at server level remains unchanged. The WebP file itself gives nothing if the browser is still given the old URL.

In WordPress, a common pitfall is incomplete handling of all image sizes. A plugin may generate WebP for the original and skip thumbnails used in listings, galleries or srcset. In practice, you need to make sure that new variants exist for every size that the theme actually displays, and regenerate thumbnails after the changes.

The second group of problems concerns images outside the media library. This includes CSS backgrounds, hero sections, sliders, files in the theme directory, ACF fields and builder elements that store URLs independently of standard WordPress mechanisms. If the site uses CSS backgrounds or builder modules, verify them manually, because that is where old files most often remain.

Cache, CDN and lazy load can also introduce a lot of confusion. After implementation, you may see the correct files on the server, and yet the user still receives an old version from cache or from an external delivery layer. That is why after changes you need to clear the WordPress, server and CDN cache, and then check in browser tools which file was actually fetched.

A separate issue is overly aggressive automation. Double optimisation, meaning compression performed in several places at once, often reduces quality and makes diagnosis harder, because it is difficult to identify which system is responsible for the final result. The safest approach is to set one main conversion location and one main cache location, instead of several overlapping mechanisms.

At the finish line, quality control remains, and it should not be postponed. Graphics with text, transparent icons, product photos or banners can look worse after conversion, even if the file is smaller. That is why the result should be assessed not only by weight, but also by sharpness, legibility and whether everything renders correctly on the site.

Which files are worth converting to WebP

To WebP, it is best to convert mainly photos and most typical raster JPG and PNG graphics that genuinely take up space and are actually downloaded on the site. The biggest gains are usually seen with large images in posts, offer pages, product listings and hero sections. These are the assets that most often generate the largest transfer.

Not every image is worth treating the same way. Photographs usually handle lossy conversion well, whereas graphics with transparency, thin lines or small text require manual checking. If an image contains text, technical details or a transparent background, always compare the result before and after conversion.

• JPG with photos: usually worth converting, because they typically deliver a noticeable reduction in size with acceptable quality.
• PNG with photos or simple graphics: often worth testing, but the result depends on the content and level of transparency.
• PNG with text, interfaces or details: convert with caution and check readability.
• SVG: usually do not convert to WebP, because the vector format should remain SVG.
• Very small files: usually do not bring any significant benefit, so they are not a priority.

In practice, it is better to set priorities than to process everything without exception. First deal with the largest and most frequently displayed images, and only then with the remaining assets. The biggest return comes from optimising large files and those visible high up on the page, not from mass conversion of small fry.

It is also worth considering the source of the images. If the files come from an external system, marketplace, product feed or are generated dynamically by a script, standard conversion in WordPress may not cover them. In such a situation, you need to establish separately who supplies the asset and check whether WebP can be enabled without manual intervention.

How to check the effectiveness of a WebP implementation

The effectiveness of a WebP implementation is assessed by checking whether the browser is actually downloading lighter image variants and whether image quality or rendering behaviour has not worsened after the change. The most important thing is what reaches the user on the web and in HTML, not the mere fact that .webp files have been generated on the server. Compare the same subpages before and after implementation, ideally in similar conditions and after clearing the cache. Check the homepage, listings, posts, products and sections with CSS backgrounds separately, because each of these areas may use different image sources.

The simplest test can be done in the browser developer tools. In the Network tab, see which files are actually being downloaded, what their transfer size is and what response type they return. If, where you expect WebP, old JPG or PNG files still appear, the implementation remains incomplete, regardless of how many files have already been created on the server.

In the page code, make sure that src, srcset, picture and CSS URLs point to the correct variants. This is particularly important in WordPress, where originals, thumbnails and intermediate sizes operate separately. If the theme, builder or gallery still refers to the old URL, the user will not see any saving.

• compare the weight of images loaded on the most important templates,
• check whether large images visible immediately after entering the site are served as WebP,
• verify CSS backgrounds, sliders, banners and hero sections,
• look at the result on mobile and desktop, because different breakpoints often use different files.

Reducing the file size alone does not solve the issue. Also check the visual quality, sharpness of details, readability of text on graphics and the correctness of transparency, because overly aggressive compression can give a worse result than leaving the original. In practice, it is worth reviewing several photos with different colour schemes, product graphics and elements with thin lines or text.

If you use cache or a CDN, run the test after clearing them and repeat it after a few page refreshes. A very common mistake is to assess an implementation on the basis of an old cached response, rather than on the basis of the asset currently being served. It is worth checking a few random URLs and making sure the server or CDN is not storing earlier versions.

Finally, assess the impact on site performance in real use. The most important are the images generating the most transfer and those that determine the first view of the page, especially the large hero image. If after implementation image transfer drops and the page layout and quality remain unchanged, that means the conversion is working as it should.