JPG to WebP Conversion Guide: Quality, File Size and Safe Web Delivery

Written by Nemanja Falb — founder and developer of TinySharp, working on WordPress image optimization, browser-based image workflows and practical website performance tooling.

Converting JPG to WebP is often useful, but the process is easy to misrepresent. A WebP file is not automatically smaller simply because it uses a newer extension, and a quality value of 80 in one encoder is not directly equivalent to 80 in another.

The safest workflow treats conversion as an experiment with three variables:

• dimensions;
• visual quality;
• final transfer size.

Start from the best available source

JPEG and lossy WebP both discard information to reduce file size. Repeatedly converting already compressed files can compound artifacts.

Prefer this order:

1. start from the original or highest-quality practical source;
2. crop and resize to the required dimensions;
3. encode the web delivery version once;
4. keep the source separately for future exports.

A common bad workflow is:

camera JPG → compressed JPG → downloaded from CMS → edited → compressed again → WebP

By the final step, the source may already contain ringing, block artifacts or lost fine detail. WebP cannot reconstruct information that was previously discarded.

Resize before comparing codecs

If a 5000-pixel JPG will display at 1200 pixels, resize it before judging JPG versus WebP. Otherwise the comparison is dominated by unnecessary dimensions.

Use the same pixel dimensions for both outputs. Comparing a 2400-pixel JPG with a 1200-pixel WebP proves that resizing helped, not that the codec alone caused the entire saving.

Do not compare quality numbers as if they were universal

A quality setting is an encoder control, not a universal visual score. “80” can produce different results across formats and tools.

Use a small test range—for example 75, 80 and 85—as starting points, then inspect the image. That range is not a rule for every asset.

Look closely at:

• faces and skin texture;
• hair, grass and fabric;
• dark gradients;
• high-contrast edges;
• small text in photographic screenshots;
• product details that influence a purchase decision.

Use a break-even rule

After conversion, keep the WebP only when it is a better delivery asset.

A simple decision rule:

• Smaller and visually acceptable: use the WebP.
• Nearly the same size: choose based on delivery consistency and workflow simplicity.
• Larger: keep the optimized JPG unless another requirement justifies WebP.
• Smaller but visibly damaged: raise quality or keep the JPG.

Do not report “savings” based on a hypothetical average when the actual output is larger.

Use representative test images

A conversion preset that works on a clean studio photo may fail on foliage or a night image. Before processing a large library, test:

• a portrait;
• a high-detail outdoor scene;
• a dark gradient;
• a product photo;
• an image with embedded text if your site uses them.

This gives you a realistic quality envelope for the batch.

Metadata and orientation need deliberate handling

JPEG files may contain EXIF metadata, camera information, location data and orientation instructions. A conversion pipeline can remove, preserve or reinterpret those fields.

For web delivery:

• remove private metadata that is not needed;
• make sure orientation is baked into the final pixels correctly;
• preserve color information when your workflow requires it;
• do not assume all metadata should always be stripped.

WebP creation is not the same as WebP delivery

This matters especially in WordPress.

You can successfully generate image.webp while the page continues to request image.jpg. The reason can be:

• old HTML cached before the conversion;
• a theme outputting the original attachment URL;
• a CSS background image bypassing rewrite logic;
• a CDN serving a cached JPG;
• responsive markup that still points to JPG variants.

Verify the live request in browser developer tools. The full issue is explained in Why WordPress Image Optimizers Need Frontend WebP Delivery.

Keep source and delivery assets separate

For many production workflows, the safest model is:

source.jpg        → archive/editing source
product-1200.webp → website delivery
product-800.webp  → responsive delivery
product-480.webp  → mobile/card candidate

The exact variants depend on the layout. The principle is that the source remains available without forcing every visitor to download it.

A hypothetical comparison example

The numbers below are an example of the decision process, not a promise of fixed savings:

Output	Dimensions	File size	Decision
Original JPG	3000×2000	1.8 MB	Source only
Resized JPG	1200×800	210 KB	Good baseline
WebP test A	1200×800	138 KB	Use if visual quality passes
WebP test B	1200×800	92 KB	Reject if artifacts are visible

The important comparison is between outputs at the same dimensions and acceptable quality.

Frontend verification checklist

1. Open the live page with browser developer tools.
2. Reload the page with the Network panel recording.
3. Filter requests by image type.
4. Inspect the final requested URL and response Content-Type.
5. Check transferred size and natural dimensions.
6. Test mobile and desktop responsive candidates.
7. Confirm caches and CDN rules are not serving an older JPG.

For a broader browser-level audit, see How to Audit Page Images With a Chrome Extension.

Frequently asked questions

Does converting JPG to WebP always reduce file size?

No. Many images become smaller, but the result depends on the source, dimensions, encoder and quality target. Keep the original or optimized JPG when the WebP output is not better.

What WebP quality should I use?

There is no universal value. Test a small range and inspect the actual image. Quality numbers are not directly comparable across encoders and formats.

Should I convert an already compressed JPG to WebP?

You can test it, but repeated lossy processing can compound artifacts. Start from the best available source when possible.

Can I delete the original JPG after conversion?

For many production workflows, keeping the source is safer. It allows future crops, higher-quality exports and rollback if delivery requirements change.

How do I confirm my website is really serving WebP?

Inspect the live image request in the browser Network panel and check the final URL, response content type and transferred file.

Continue the workflow

Use the TinySharp WebP Converter for controlled conversion, the Image Compressor when the existing format is already correct, and the Chrome Extension to verify the live result.