WebP vs. AVIF vs. JPEG for WordPress

Choosing between WebP, AVIF and JPEG for WordPress is not simply a question of picking whichever format produces the smallest file.

The right format depends on several factors:

• image content;
• visual quality requirements;
• browser compatibility;
• WordPress support;
• server image-processing support;
• encoding speed;
• file size;
• transparency requirements;
• your image optimization workflow.

JPEG remains one of the most universally compatible formats for photographic content. WebP provides modern compression with broad browser and WordPress support. AVIF can often achieve excellent compression efficiency and supports advanced image features, but encoding and server support deserve closer attention.

More importantly, converting a badly sized 4000-pixel image from JPEG to AVIF does not magically make the image strategy good. Format, dimensions, compression, responsive delivery and loading behavior all work together.

This guide compares WebP vs. AVIF vs. JPEG for WordPress, explains native WordPress support, examines the real performance trade-offs and shows how to choose formats without relying on simplistic “X% smaller” claims that rarely survive contact with an actual Media Library.

Quick comparison: WebP vs. AVIF vs. JPEG

Feature	JPEG	WebP	AVIF
Lossy compression	Yes	Yes	Yes
Lossless compression	No	Yes	Yes
Transparency	No	Yes	Yes
Animation	No	Yes	Supported by the format, but workflow support varies
HDR / wide color capabilities	Limited compared with modern formats	More limited than AVIF	Strong
Native WordPress upload support	Yes	Yes	Yes on supported WordPress/server environments
Typical browser compatibility	Extremely broad	Broad across modern browsers	Broad across current major browsers
Encoding complexity	Low	Moderate	Can be higher
Best general use	Maximum compatibility and established workflows	Strong default modern web format	High-efficiency modern image delivery

This table provides direction, not a universal winner.

The same photograph encoded by three different tools at three arbitrary quality settings does not produce a scientifically meaningful format comparison.

What is JPEG?

JPEG is a long-established raster image format built primarily around lossy compression.

It is particularly well suited to continuous-tone photographic imagery such as:

• photographs;
• product photography;
• landscapes;
• portraits;
• complex gradients.

A JPEG commonly uses one of these extensions:

.jpg
.jpeg

JPEG is lossy

Lossy compression means information is discarded to reduce file size.

The more aggressively an image is compressed, the greater the chance of visible artifacts such as:

• blocking;
• ringing;
• smearing;
• loss of fine detail.

The goal is therefore not:

smallest possible file

but:

smallest acceptable file
at the required visual quality

Why JPEG is still relevant

JPEG is old, but old does not automatically mean useless. Humanity occasionally invents things worth keeping.

Its advantages include:

• extremely broad software support;
• excellent compatibility with existing workflows;
• fast encoding and decoding;
• mature editing tools;
• predictable behavior;
• good efficiency for many photographic images.

For some websites, a well-sized and properly compressed JPEG can still be entirely reasonable.

JPEG’s main limitations

JPEG does not provide the same compression efficiency or feature set as newer formats.

No transparency

Traditional JPEG does not provide an alpha channel for transparent areas.

That makes it unsuitable for assets such as:

• logos requiring transparency;
• cut-out products;
• UI overlays;
• graphics placed on variable backgrounds.

No lossless mode

Standard JPEG is fundamentally designed around lossy image compression.

Compression artifacts can become obvious

Strong compression is particularly visible around:

• sharp edges;
• text;
• logos;
• high-contrast graphics.

JPEG is therefore usually a better fit for photography than interface graphics containing precise edges.

What is WebP?

WebP is a modern image format originally developed by Google for web delivery.

Unlike JPEG, WebP supports both:

• lossy compression;
• lossless compression.

It also supports:

• alpha transparency;
• animation.

A WebP file commonly uses:

.webp

WordPress support for WebP

WordPress introduced native WebP support in WordPress 5.8.

This means supported WordPress installations can treat WebP as an image format within the Media Library rather than requiring the old collection of MIME-type workarounds that used to circulate through WordPress snippets.

The official WordPress 5.8 documentation documents the addition of WebP support.

Why WebP became popular on WordPress sites

WebP occupies an attractive middle ground.

It offers:

• good compression efficiency;
• transparency;
• strong browser compatibility;
• native WordPress support;
• well-established server tooling.

That makes it a practical modern default for many WordPress environments.

What is AVIF?

AVIF is an image format based on technology from the AV1 codec ecosystem.

It is designed to provide efficient image compression while supporting modern image capabilities.

An AVIF image normally uses:

.avif

AVIF supports:

• lossy compression;
• lossless compression;
• alpha transparency;
• high bit depth;
• wide color gamut;
• HDR image data.

WordPress support for AVIF

Native AVIF support was added in WordPress 6.5.

On a compatible environment, WordPress can:

• upload AVIF files;
• edit them;
• resize them;
• save generated derivatives.

The official WordPress AVIF developer note explains the implementation and requirements.

AVIF support depends on the server

WordPress supporting AVIF does not guarantee that every hosting environment can process AVIF.

WordPress uses server image-processing libraries such as:

• Imagick;
• GD.

The underlying library must support AVIF for WordPress to perform the corresponding image-processing operations.

Check Site Health

You can inspect media capabilities through:

Tools
→
Site Health
→
Info
→
Media Handling

This is preferable to assuming AVIF support because the WordPress version number happens to be high enough.

WebP vs. AVIF vs. JPEG: which creates the smallest file?

There is no reliable universal answer for every image.

AVIF can often produce excellent compression efficiency, followed by WebP and then JPEG in many photographic scenarios.

But this hierarchy is not guaranteed for:

• every source;
• every encoder;
• every quality level;
• every resolution;
• every image type.

Never compare formats using identical quality numbers

This is a surprisingly common mistake.

Comparing:

JPEG quality 80

WebP quality 80

AVIF quality 80

does not mean the three encoders are targeting identical perceptual quality.

Quality scales are encoder-specific controls, not standardized cross-format measurements.

A fair comparison requires comparable visual quality

A useful test is:

same source
+
same final dimensions
+
similar perceived quality
↓
compare resulting bytes

For serious optimization work, compare both:

• visual output;
• file size.

Saving 40 KB while visibly damaging a product photograph is not an optimization triumph.

AVIF often excels at low bitrates

AVIF’s compression technology can perform particularly well when trying to preserve acceptable image quality at relatively small file sizes.

This can be attractive for:

• large hero images;
• editorial photography;
• e-commerce product imagery;
• high-resolution responsive candidates.

But encoding cost and server support should also be considered.

WebP remains an excellent practical default

For many WordPress installations, WebP offers a useful balance between:

• compression;
• compatibility;
• processing speed;
• server support;
• tooling maturity.

This makes WebP especially attractive when you want a modern format without making the image pipeline unnecessarily complex.

JPEG remains useful as a compatibility baseline

JPEG is still valuable when:

• maximum compatibility matters;
• external systems expect JPEG;
• the image pipeline does not support newer formats reliably;
• encoding speed matters more than maximum compression efficiency;
• the resulting JPEG is already efficiently optimized.

A 180 KB correctly sized JPEG can easily be a better web asset than a 500 KB WebP produced from a needlessly large source.

Image dimensions often matter more than format

Suppose a website displays a card at:

400 × 267

but downloads:

4000 × 2667

Converting that huge JPEG to WebP or AVIF reduces transfer size, but it does not address the fundamental problem.

The website is still serving far more pixels than the layout requires.

A better strategy

correct source dimensions
+
appropriate WordPress image size
+
responsive srcset
+
efficient format
+
sensible compression

WordPress’s image-size architecture is explained in How WordPress generates image sizes.

How WordPress generates derivatives

When WordPress processes an image, it can generate multiple intermediate image files.

For example:

photo.jpg
photo-300x200.jpg
photo-768x512.jpg
photo-1024x683.jpg

The same principle applies when the processing workflow uses supported modern formats.

Read How WordPress generates image thumbnails for the detailed upload-to-file pipeline.

WordPress can change generated output formats

WordPress provides the:

image_editor_output_format

filter.

This enables developers to define a different output format for generated image sub-sizes.

Example: output WebP for JPEG sources

add_filter(
    'image_editor_output_format',
    function ( $formats ) {

        $formats['image/jpeg'] =
            'image/webp';

        return $formats;
    }
);

Example: output AVIF for JPEG sources

add_filter(
    'image_editor_output_format',
    function ( $formats ) {

        $formats['image/jpeg'] =
            'image/avif';

        return $formats;
    }
);

Use this only after confirming that the active image-processing environment supports the intended destination format.

Do not confuse format conversion with optimization

Changing:

photo.jpg

to:

photo.webp

is format conversion.

It becomes useful optimization only if the resulting asset is better for the intended delivery scenario.

For example:

JPEG:
220 KB

WebP:
270 KB

would not represent a file-size improvement simply because WebP is newer.

Compression settings matter enormously

Each format can be encoded at different quality levels.

A high-quality AVIF can be larger than an aggressively compressed JPEG.

A poor WebP export can contain visible artifacts.

An over-compressed JPEG can be tiny but unusable.

The correct question is therefore:

Which format gives us
the best acceptable visual result
for the lowest practical cost?

WordPress provides image quality filters

Developers can influence image quality using WordPress’s image-editor APIs and filters.

One relevant filter is:

wp_editor_set_quality

The MIME type is available to the filter, allowing quality decisions to vary by output format.

Example

add_filter(
    'wp_editor_set_quality',
    function (
        $quality,
        $mime_type
    ) {

        if (
            'image/avif'
            === $mime_type
        ) {
            return 75;
        }

        return $quality;
    },
    10,
    2
);

Do not copy one arbitrary quality value across an entire Media Library without testing visual results.

WebP transparency vs. JPEG

WebP can preserve an alpha channel.

This makes it useful for images such as:

• transparent product cut-outs;
• logos;
• decorative graphics;
• overlays.

JPEG cannot preserve transparent pixels.

If a transparent source is converted to JPEG, the transparent area must effectively become opaque.

AVIF transparency

AVIF can also support transparency.

This means both WebP and AVIF can replace PNG in some web scenarios where transparency is required.

However, do not blindly convert every PNG.

Simple graphics, screenshots and assets with sharp edges may respond differently to different codecs and compression settings.

What about PNG?

PNG is not the focus of this comparison, but it remains relevant.

PNG uses lossless compression and is often useful for:

• graphics requiring exact pixels;
• screenshots;
• simple illustrations;
• transparent graphics.

For photographic content, PNG can become dramatically larger than necessary.

WebP or AVIF may often provide much smaller outputs depending on the quality requirements.

Photographs: JPEG vs. WebP vs. AVIF

For typical photography:

JPEG

Good when:

• compatibility is the priority;
• the existing asset is already optimized;
• your tooling is JPEG-centric.

WebP

Good when:

• you want a modern general-purpose format;
• you want strong browser compatibility;
• you need a mature WordPress workflow;
• you want a balance between compression and processing cost.

AVIF

Good when:

• compression efficiency is especially important;
• the hosting environment supports AVIF processing;
• your tooling can generate good AVIF output;
• encoding cost is acceptable.

Logos and graphics

For logos, icons and vector-style graphics, first ask whether the asset should actually be rasterized at all.

SVG may be more appropriate for suitable vector artwork.

If a raster format is required:

• WebP can provide lossless output and transparency;
• AVIF can provide transparency and advanced compression;
• JPEG is generally a poor choice when transparent or razor-sharp edges matter.

Screenshots

Screenshots contain:

• text;
• sharp UI edges;
• flat colors;
• gradients.

They therefore behave differently from photographs.

Do not assume the format that wins for a landscape photograph will also win for a WordPress dashboard screenshot.

Compare lossless or near-lossless WebP, AVIF and PNG where visual precision matters.

AVIF encoding can be more expensive

One trade-off with sophisticated compression is encoding complexity.

AVIF encoding can consume more CPU time than simpler or more mature JPEG workflows, depending on the encoder and chosen settings.

This matters particularly when WordPress must generate many image sub-sizes during:

• uploads;
• bulk optimization;
• thumbnail regeneration;
• large media migrations.

Consider server resources during bulk conversion

Imagine:

30,000 image attachments
×
6 sub-sizes

A complete conversion or regeneration can involve a very large number of image-encoding operations.

Before bulk processing:

• back up the Media Library;
• check disk space;
• verify PHP memory;
• verify image-library support;
• test a small batch;
• measure processing time;
• inspect output quality.

Format choice and Core Web Vitals

Reducing image transfer size can help page performance, particularly when the image is the Largest Contentful Paint element.

For example:

LCP image:
1.4 MB JPEG

optimized alternative:
350 KB modern-format asset

can reduce resource download time considerably on slower connections.

But format conversion alone does not solve every image-performance problem.

Read Core Web Vitals and image weight for the complete relationship between image bytes, LCP, responsive sizing and CLS.

A smaller AVIF can still have poor LCP

Imagine an AVIF hero image weighing only:

120 KB

but JavaScript discovers it:

2 seconds after navigation

The file is efficient.

The loading strategy is not.

LCP depends on more than resource size, including:

• server response;
• resource discovery;
• loading priority;
• download duration;
• render delay.

Format choice does not solve CLS

Changing:

hero.jpg

to:

hero.avif

does not reserve layout space.

Use proper intrinsic dimensions:

<img
    src="hero.avif"
    width="1600"
    height="900"
    alt=""
>

or another reliable method of reserving the correct aspect ratio.

Responsive images remain more important than choosing one universal format

A WordPress image can expose multiple responsive candidates:

320w
640w
768w
1024w
1600w

The browser can select the candidate appropriate for its current rendering environment.

This avoids delivering a 1600-pixel image when a 320-pixel source is sufficient.

Saving bytes through format conversion and then wasting them again through inappropriate image dimensions would be a remarkably human optimization strategy.

Use srcset and sizes correctly

WordPress can generate responsive markup similar to:

<img
    src="photo-768x512.webp"
    srcset="
        photo-300x200.webp 300w,
        photo-768x512.webp 768w,
        photo-1024x683.webp 1024w
    "
    sizes="
        (max-width: 768px) 100vw,
        768px
    "
    width="768"
    height="512"
    alt=""
>

This lets the browser choose an appropriate resource.

Format optimization and responsive sizing should work together.

Should you convert your entire WordPress Media Library to WebP?

Not automatically.

First answer:

• What formats already exist?
• How large are the current files?
• Are images being served at appropriate dimensions?
• Will existing URLs change?
• Will page-builder references remain valid?
• Does the server support the new format?
• Can the original files be restored?
• Are all generated sub-sizes being handled?

Should you convert everything to AVIF?

The answer is also no.

AVIF can be extremely useful, but a site-wide format policy should consider:

• hosting support;
• image-processing performance;
• quality requirements;
• browser audience;
• existing integrations;
• third-party export requirements;
• editor workflows.

A mixed-format WordPress site is normal

There is no requirement that every image on a website use the same format.

A sensible Media Library might contain:

JPEG
for some legacy photography

WebP
for modern general-purpose images

AVIF
for optimized high-resolution assets

PNG
for selected lossless graphics

SVG
for suitable vector assets

Choose formats according to use case rather than ideological purity about file extensions.

Original format vs. generated output format

It is useful to distinguish:

uploaded original

from:

generated derivative format

A workflow can potentially retain:

original JPEG

while generating:

WebP sub-sizes

or:

AVIF sub-sizes

where WordPress, the image library and the surrounding implementation support that strategy.

Why keeping originals can be valuable

Preserving an original gives you a higher-quality source if you later need to:

• change quality settings;
• switch output formats;
• regenerate image sizes;
• create larger derivatives;
• undo a poor conversion.

Repeated lossy transcoding is not an ideal archival workflow.

Avoid repeated lossy conversions

A workflow like:

JPEG
↓
WebP
↓
JPEG
↓
AVIF

can repeatedly re-encode already compressed image information.

For future conversions, prefer starting from the highest-quality retained source available.

How TheOneWP Image Optimizer fits into the workflow

TheOneWP Image Optimizer provides a WordPress-native workflow for optimizing Media Library images.

The module checks which output formats are actually available in the current server environment rather than simply assuming that WebP or AVIF encoding exists.

That distinction is important because WordPress-level format support and server-level encoding support are not identical concepts.

Do not assume AVIF or WebP is always available to the optimizer

The available conversion options depend on the server’s media-processing capabilities.

A production workflow should therefore use:

detected server capability

rather than:

hardcoded assumption

before presenting or running a format conversion.

Test image quality before bulk optimization

Take a representative sample containing:

• a portrait;
• a landscape photograph;
• a product image;
• a dark image;
• a high-detail image;
• a gradient;
• a screenshot;
• a transparent asset.

Then compare your actual target formats.

Inspect at normal viewing size

Look for:

• detail loss;
• banding;
• edge artifacts;
• color shifts;
• transparency problems.

Also inspect file size

An output should justify its visual trade-off.

Replacing image files can create cache issues

If format conversion changes the URL from:

photo.jpg

to:

photo.webp

the browser sees a different resource URL.

If an optimization workflow instead replaces bytes behind the same URL, browser or CDN caches can continue serving old content.

This problem is explained in WordPress image cache-busting, explained.

Changing formats can affect external references

Before deleting old image files, remember that their URLs may be referenced from:

• external websites;
• social posts;
• emails;
• structured data;
• custom fields;
• page-builder content;
• cached HTML.

A format migration is therefore not only an encoding problem.

It can also be a URL-management problem.

Do you need to regenerate thumbnails after changing strategy?

If you change how new image sub-sizes are generated, existing attachments do not automatically travel back in time and recreate themselves.

Older media may therefore retain previous formats or dimensions.

Read Regenerating WordPress image thumbnails before running a large historical conversion.

Verify what WordPress actually generated

Do not assume that because a format or image size is configured, every attachment contains the expected derivative.

Source dimensions, processing failures and historical uploads can create differences between:

what is configured

and:

what physically exists

If you need the URL of a specific generated representation, see Finding a specific WordPress image size’s URL.

WebP vs. AVIF for WordPress

If JPEG is removed from the comparison and the decision is specifically between WebP and AVIF, the trade-off becomes clearer.

Choose WebP when

• you want a mature modern web format;
• you want broad compatibility;
• you want transparency support;
• server processing is already reliable;
• you value a good compression-to-complexity balance.

Choose AVIF when

• maximum compression efficiency is important;
• the server supports AVIF correctly;
• your encoder produces high-quality results;
• encoding cost is acceptable;
• you can test the output across representative images.

AVIF vs. JPEG for WordPress

For modern photographic delivery, AVIF can often achieve much smaller files than JPEG at comparable visual quality.

But JPEG retains advantages in:

• legacy compatibility;
• editing workflow support;
• encoding speed;
• third-party compatibility.

If a WordPress site is entirely under your control and the environment supports AVIF well, the newer format becomes much easier to justify.

WebP vs. JPEG for WordPress

WebP has become a relatively straightforward modernization path for many WordPress websites.

Compared with JPEG, WebP adds:

• lossless mode;
• transparency;
• animation;
• generally improved compression opportunities.

JPEG still wins on universality and established interoperability.

Do modern formats improve SEO?

Google does not reward a page merely because an image filename ends in:

.webp

or:

.avif

The SEO benefit is indirect.

Efficient image delivery can improve:

• loading performance;
• bandwidth usage;
• mobile user experience;
• Core Web Vitals when image transfer is a bottleneck.

Those performance improvements can contribute to a healthier technical SEO profile.

Do not sacrifice image quality for a PageSpeed score

Image optimization should support the content rather than destroy it.

For an e-commerce site, an over-compressed product image can affect:

• perceived product quality;
• detail visibility;
• customer confidence;
• conversion.

The best technical performance metric is not useful if the actual content becomes worse.

A practical WordPress format strategy

Step 1: audit current image usage

Determine:

• current formats;
• typical file sizes;
• typical resolutions;
• largest images;
• LCP images;
• repeated oversized assets.

Step 2: fix dimensions first

Do not send 4000 pixels to a 400-pixel card.

Step 3: verify responsive images

Inspect:

src
srcset
sizes

Step 4: test WebP and AVIF output

Use the same source dimensions and comparable visual quality.

Step 5: verify server capabilities

Confirm the hosting environment can encode and process the chosen format.

Step 6: choose quality settings

Test different content types rather than relying on a universal number.

Step 7: preserve a recovery path

Do not destroy the only useful high-quality source during a mass optimization.

Step 8: test a small batch

Verify:

• Media Library behavior;
• frontend URLs;
• responsive images;
• page-builder content;
• visual quality;
• file size.

Step 9: measure performance

Check actual transferred bytes and Core Web Vitals rather than assuming the format change worked.

Step 10: expand the optimization only after validation

Bulk conversion is not the stage at which you want to discover that your hero gradients now look like geological sediment.

Common WebP, AVIF and JPEG mistakes

Assuming AVIF always creates the smallest file

Test your actual source and encoder.

Assuming WebP is automatically optimized

A WebP can still be oversized or poorly encoded.

Assuming JPEG is automatically bad

A correctly sized optimized JPEG can remain perfectly reasonable.

Comparing identical quality numbers

Quality scales are not directly equivalent across codecs.

Converting images without resizing them

Pixel dimensions can matter as much as format.

Ignoring responsive image selection

A modern format does not compensate for downloading a candidate far larger than necessary.

Assuming WordPress support guarantees server encoding support

AVIF processing depends on the actual media libraries available in the hosting environment.

Deleting originals immediately

Keep a recovery source where your workflow requires one.

Repeatedly transcoding lossy images

Prefer generating future versions from the best retained source.

Ignoring historical thumbnails

Changing output strategy does not necessarily update existing derivatives automatically.

Ignoring cached URLs

File replacement and browser/CDN caching are separate concerns.

Optimizing only desktop images

Mobile users often benefit most from reduced transfer size.

Trusting theoretical savings instead of measuring production output

Your Media Library is the benchmark that matters.

WebP vs. AVIF vs. JPEG checklist

• Check the actual dimensions of source images.
• Use appropriately sized WordPress image derivatives.
• Verify responsive srcset and sizes.
• Use JPEG when maximum compatibility or existing workflow support matters.
• Use WebP when you want a strong modern general-purpose option.
• Consider AVIF when compression efficiency justifies the additional processing requirements.
• Verify AVIF support in the hosting environment.
• Do not compare codecs solely by their numerical quality setting.
• Compare outputs at similar perceived visual quality.
• Test photographs, screenshots, gradients and transparent assets separately.
• Do not assume one format wins for every image type.
• Preserve high-quality originals where future regeneration matters.
• Avoid repeated lossy transcoding.
• Check file size after conversion.
• Check visual quality after conversion.
• Test a small Media Library batch first.
• Check generated thumbnails and responsive candidates.
• Account for existing image URLs before deleting old files.
• Review caching when files are replaced in place.
• Measure Core Web Vitals before and after major changes.

Related WordPress image guides

Continue with these related guides and tools:

• Core Web Vitals and image weight
• How WordPress generates image sizes
• How WordPress generates image thumbnails
• Regenerating WordPress image thumbnails
• Finding a specific WordPress image size’s URL
• WordPress image cache-busting, explained
• Image Optimizer
• Image Sizes List

Final thoughts

There is no universal winner in the WebP vs. AVIF vs. JPEG debate.

A useful summary is:

JPEG
=
maximum maturity and compatibility

WebP
=
strong modern balance
of efficiency and practicality

AVIF
=
excellent compression potential
with more demanding processing considerations

For many modern WordPress sites, WebP is a practical general-purpose choice.

AVIF becomes compelling when its compression advantages matter and the hosting, tooling and optimization pipeline support it reliably.

JPEG remains useful when interoperability, simplicity or existing workflows outweigh the additional savings available from newer formats.

But format choice is only one part of image performance.

The complete equation is closer to:

correct dimensions
+
appropriate image size
+
responsive delivery
+
efficient format
+
sensible quality
+
good loading strategy
=
effective WordPress image performance

Do not convert an oversized original to AVIF and declare victory. Fix the dimensions, check the generated WordPress sizes, inspect what the browser actually downloads and then choose the format that delivers the best balance of quality, compatibility and bytes for your real content.