Back to tutorials
Tutorial

cPanel Image Conversion Tutorial (2026): Serve WebP/AVIF Automatically with LiteSpeed or Nginx

cPanel image conversion tutorial for 2026: auto-serve WebP/AVIF with LiteSpeed or Nginx, plus safe rollback steps.

By Anurag Singh
Updated on Sep 02, 2026
Category: Tutorial
Share article
cPanel Image Conversion Tutorial (2026): Serve WebP/AVIF Automatically with LiteSpeed or Nginx

Images still account for most page weight on typical hosting accounts. The fix is simple, even if it’s not exciting. Stop sending 600–1200 KB JPEGs when the browser would accept a 120–300 KB AVIF or WebP instead.

This cPanel image conversion tutorial covers two practical rollouts that don’t require rebuilding your stack:

(1) LiteSpeed + QUIC.cloud (common on cPanel servers), and (2) Nginx rewrite rules for setups where you control the web server layer.

You’ll also get a rollback plan, a quick QA checklist, and a simple way to estimate bandwidth savings before you touch production.

What you’ll build (and what you need)

  • Goal: Browsers that support AVIF/WebP get those formats; older browsers keep getting the original JPG/PNG.
  • Where it works best: WordPress and other CMS sites with lots of media.
  • cPanel paths you’ll actually use: /home/USERNAME/public_html/, .htaccess (Apache/LiteSpeed), and optional Nginx include snippets.

Prereqs:

  • cPanel access (account-level) for plugin-based conversion, or WHM/root for a server-wide rollout.
  • A backup before you change rewrite rules or enable automated conversions. If you run WHM, schedule backups first.

If you need a hosting plan with predictable CPU/RAM for conversion jobs (image optimization can spike load), use a HostMyCode VPS instead of a crowded environment.

Step 1: Baseline your current image weight (10 minutes)

Don’t guess. Build a baseline from real pages and real files.

  1. Pick 3 URLs: your home page, a category/listing page, and a heavy post/product page.

  2. Check transfer size in your browser dev tools:

    • Chrome/Edge: DevTools → Network → reload → review “Transferred” and sort by “Size”.
    • Write down the top 10 images by size.

  3. On the server (SSH into the account or server), sample your uploads directory:

    cd /home/USERNAME/public_html
# WordPress default uploads path
cd wp-content/uploads
# Show the 20 largest images (JPG/PNG)
find . -type f \( -iname '*.jpg' -o -iname '*.jpeg' -o -iname '*.png' \) -printf '%s %p\n' | sort -nr | head -20

Capture two numbers: your typical “hero image” size and your worst offenders.

After conversion, validate those files first.

Step 2: Choose your rollout method (LiteSpeed vs Nginx)

On cPanel servers, the choice usually comes down to what answers HTTP requests.

  • LiteSpeed Enterprise / OpenLiteSpeed behind cPanel: Use LSCache + QUIC.cloud image optimization. It’s low-maintenance because it avoids brittle rewrite logic.
  • Nginx in front (reverse proxy) or an Nginx-only stack: Use rewrite rules to serve .avif / .webp variants when they exist.

If you’re unsure, check the response headers:

curl -I https://example.com/ | egrep -i 'server:|x-powered-by:|x-litespeed'

If you see Server: LiteSpeed or X-LiteSpeed-Cache, use the LiteSpeed path.

Option A (recommended on cPanel): LiteSpeed + QUIC.cloud auto WebP/AVIF

This is usually the cleanest approach on shared hosting and many cPanel VPS setups.

The browser advertises support via the Accept header. LiteSpeed then serves the best match. You don’t have rewrite rules to maintain.

A1) Install and verify LSCache (WordPress)

  1. In WordPress Admin: Plugins → Add New → search LiteSpeed Cache → Install → Activate.
  2. Go to LiteSpeed Cache → Toolbox → Report and confirm it detects LiteSpeed (no “Apache only” warning).

On cPanel + LiteSpeed, LSCache typically works out of the box.

If you’re picking infrastructure and want fewer moving parts, managed VPS hosting keeps the web stack consistent.

A2) Enable image optimization (WebP/AVIF) safely

In LiteSpeed Cache → Image Optimization:

  • Auto Request Cron: ON (hands-off queues)
  • Optimize Original Images: OFF initially (start by serving modern formats; avoid changing originals during the first rollout)
  • Image WebP Replacement: ON
  • WebP For Extra srcset: ON (helps responsive images)
  • AVIF Replacement: ON (if available in your build; many 2026 installs support it through QUIC.cloud)

Then connect QUIC.cloud:

  1. LiteSpeed Cache → General → Request Domain Key
  2. Follow the QUIC.cloud prompts to link the site.
  3. Back in Image Optimization, click Send Optimization Request for a small batch first.

A3) QA: confirm correct content negotiation

Pick one image URL. Test it with different Accept headers:

# Browser that “accepts” AVIF
curl -I -H 'Accept: image/avif,image/webp,image/*,*/*;q=0.8' https://example.com/wp-content/uploads/2026/08/hero.jpg | egrep -i 'content-type|vary|content-length|cache-control'

# Browser that only “accepts” WebP
curl -I -H 'Accept: image/webp,image/*,*/*;q=0.8' https://example.com/wp-content/uploads/2026/08/hero.jpg | egrep -i 'content-type|vary'

# Legacy/forced: no WebP/AVIF
curl -I -H 'Accept: image/jpeg,image/*,*/*;q=0.8' https://example.com/wp-content/uploads/2026/08/hero.jpg | egrep -i 'content-type|vary'

What you want to see:

  • Vary: Accept (so caches don’t mix formats)
  • Content-Type switching to image/avif or image/webp when appropriate

A4) Common LiteSpeed pitfalls (and quick fixes)

  • Mixed content / CDN rewriting issues: Purge all caches. If you use a CDN, purge there too.
  • Format served but broken in Safari: Disable AVIF replacement first and keep WebP on. Safari support is good in 2026, but edge versions and intermediaries can still get weird.
  • CPU spikes during bulk optimize: Keep batches small and run off-peak. On a VPS, scale up for a day, convert, then scale back.

Option B: Nginx rewrites to serve .avif/.webp if the file exists

This route fits VPS/dedicated servers where you own the Nginx config.

It also fits cPanel setups where Nginx sits in front as a reverse proxy.

The behavior is simple. If image.jpg is requested and image.jpg.avif exists, serve AVIF.

If AVIF isn’t available, try WebP. If neither exists, serve the original.

Two notes before you touch config:

  • You still need a way to generate the AVIF/WebP files (plugin, CI job, or a one-time batch conversion).
  • You must set Vary: Accept (or keep URLs distinct) to avoid cache poisoning.

B1) Generate AVIF/WebP variants (WordPress-friendly)

If you’re on WordPress and skipping LiteSpeed’s pipeline, use an image optimization plugin that writes WebP/AVIF files to disk (not only on-the-fly).

Make sure it stores variants next to the originals. Nginx needs to detect them.

After generation, you should see pairs like:

  • hero.jpg
  • hero.jpg.webp
  • hero.jpg.avif

Confirm with:

cd /home/USERNAME/public_html/wp-content/uploads
ls -la 2026/08 | egrep 'hero\.(jpg|webp|avif)'

B2) Add Nginx config (server-wide example)

Edit your site’s Nginx server block. On Ubuntu, this is commonly:

  • /etc/nginx/sites-available/example.com (symlinked into sites-enabled)

Add this inside the server { ... } block, above your main location /:

# Prefer AVIF/WebP variants for JPG/PNG if present
location ~* \.(jpe?g|png)$ {
  add_header Vary Accept always;

  # Try AVIF first, then WebP, then original
  set $avif "";
  set $webp "";

  if ($http_accept ~* "image/avif") {
    set $avif ".avif";
  }
  if ($http_accept ~* "image/webp") {
    set $webp ".webp";
  }

  try_files $uri$avif $uri$webp $uri =404;
}

Then test and reload:

nginx -t
systemctl reload nginx

B3) If you run Nginx in front of Apache (common on hosting VPS)

If your stack is Nginx reverse proxy → Apache, let Nginx serve images.

This keeps Apache workers focused on dynamic requests.

If you haven’t set up that topology yet, follow our guide: Nginx in front of Apache reverse proxy setup.

In that architecture, ensure Nginx serves /wp-content/uploads directly. Example snippet:

location ^~ /wp-content/uploads/ {
  access_log off;
  expires 30d;
  add_header Cache-Control "public, max-age=2592000, immutable";
  try_files $uri $uri/ =404;
}

# Then the AVIF/WebP block from above can still apply

B4) QA for Nginx path

Run the same curl tests as in the LiteSpeed section, but request the original JPG URL.

If the rule works, the server returns Content-Type: image/avif or image/webp while you’re still hitting the JPG path.

curl -I -H 'Accept: image/avif,image/webp,image/*,*/*;q=0.8' https://example.com/wp-content/uploads/2026/08/hero.jpg | egrep -i 'content-type|vary'

If it always stays image/jpeg, check:

  • Do the variant files exist (hero.jpg.avif / hero.jpg.webp)?
  • Is another location block matching first?
  • Are you serving uploads from a CDN that bypasses Nginx?

Step 3: Make it safe on shared hosting (account-level .htaccess approach)

If you don’t control Nginx and you’re on Apache/LiteSpeed, you can still serve variants through .htaccess.

This approach is conservative. It tends to behave best on LiteSpeed.

It’s also common on cPanel shared hosting.

Edit:

  • /home/USERNAME/public_html/.htaccess

Add the rules below (AVIF first, then WebP). Place them near the top, before WordPress rewrites:

<IfModule mod_rewrite.c>
RewriteEngine On

# Only for existing JPG/PNG requests
RewriteCond %{REQUEST_FILENAME} -f

# Prefer AVIF
RewriteCond %{HTTP_ACCEPT} image/avif
RewriteCond %{REQUEST_FILENAME}.avif -f
RewriteRule ^(.+\.(?:jpe?g|png))$ $1.avif [T=image/avif,E=accept:1,L]

# Else prefer WebP
RewriteCond %{HTTP_ACCEPT} image/webp
RewriteCond %{REQUEST_FILENAME}.webp -f
RewriteRule ^(.+\.(?:jpe?g|png))$ $1.webp [T=image/webp,E=accept:1,L]
</IfModule>

<IfModule mod_headers.c>
# Avoid cache mixing across Accept variants
Header append Vary Accept env=accept
</IfModule>

Rollback plan: If anything looks wrong, comment out this block and save.

Originals will be served immediately.

Step 4: Verify caching and avoid “wrong format” bugs

Most failures aren’t caused by conversion.

They happen when a cache stores the wrong variant and serves it to everyone.

  • Always set: Vary: Accept for negotiated formats.
  • If you use a CDN: Confirm it respects Vary or configure separate cache keys per Accept. If you can’t, use distinct URLs (serve .webp explicitly).
  • Browser cache: QA in a private window and with cache disabled in DevTools.

While you’re changing caching behavior, keep an external monitor running so you catch issues fast.

This guide covers both off-server checks and on-server endpoints: Uptime monitoring tutorial for VPS and dedicated hosting.

Step 5: Performance checklist (what “good” looks like)

After rollout, transfers should drop without increasing errors or backend load.

  • Transferred bytes: On image-heavy pages, a 25–60% reduction is common once most images have AVIF/WebP variants.
  • TTFB: Should stay flat. If TTFB rises, you’re probably generating images on-the-fly or forcing backend hits.
  • CPU: Spikes during batch processing are normal; serving optimized images should not spike.

On a VPS, the biggest win is usually efficient static delivery.

It also helps keep PHP workers free.

If you’re tuning the rest of the stack, pair this with: VPS performance optimization for WordPress.

Step 6: Troubleshooting quick diagnostics

Problem: AVIF/WebP files exist but never get served

  • Check headers: curl -I and confirm your server returns Vary: Accept and switches Content-Type.
  • Check rule order: Another rewrite/location may match first.
  • Check file naming: Your converter may create hero.webp instead of hero.jpg.webp. Update rewrites to match your actual filenames.

Problem: Some images 404 after enabling rewrites

  • Make sure your rules fall back to the original file. In Nginx, keep $uri as the last try_files option.
  • On Apache, remove the -f check temporarily to confirm rewrite matching, then restore it.

Problem: Random users see broken images (cache poisoning)

  • Confirm Vary: Accept is present on the image responses (not just HTML).
  • If your CDN ignores Vary, disable negotiation at origin and use explicit .webp URLs, or configure the CDN cache key on Accept.

Problem: Conversion jobs overload the server

  • Throttle batches, run off-peak, and limit parallel conversions.
  • Consider moving the site to a plan with predictable resources during the conversion window (VPS/dedicated).

Step 7: Operational notes for resellers and multi-account cPanel servers

If you run reseller hosting, avoid server-wide changes that surprise clients.

Keep the rollout controlled and reversible.

  1. Enable optimization on a single “pilot” account first.
  2. Document rollback steps (remove plugin, disable the setting, or comment the rewrite block).
  3. Roll out account-by-account, starting with the heaviest bandwidth users.

If you’re migrating accounts between servers, apply your image strategy after the move.

Keep the cutover simple, then optimize.

For the migration itself, use these downtime-safe DNS steps: DNS cutover checklist.

Summary: a practical 2026 rollout plan

  • Measure the worst images first, not the averages.
  • On cPanel + LiteSpeed, prefer LSCache + QUIC.cloud for lower risk.
  • On Nginx, serve AVIF/WebP only if the variant exists, and always set Vary: Accept.
  • Keep rollback easy: one toggle or one rewrite block.

If you want predictable performance while you run conversions and tune caching, start on a HostMyCode VPS.

If you’d rather not touch web server config, managed VPS hosting gives you a safer path to implement these changes.

If your site is image-heavy and you’re running into bandwidth or CPU ceilings, a VPS often fixes the underlying resource crunch. HostMyCode can provision a VPS if you want full server control, or you can choose managed VPS hosting if you want the optimization handled with less risk.

FAQ

Do I need AVIF, or is WebP enough?

WebP alone is a strong upgrade and has broad support. AVIF often compresses smaller, so enable it if your stack serves it reliably and your CDN respects Vary: Accept.

Will image conversion hurt SEO or break social previews?

If the original JPG/PNG URLs keep working and you only negotiate formats based on Accept, SEO and previews stay stable. Social crawlers often fetch originals and ignore AVIF/WebP anyway.

Should I delete original JPG/PNG files after conversion?

No. Keep originals as the compatibility fallback and as your “source of truth” for future re-encoding.

How do I confirm a page is actually using AVIF/WebP?

Open DevTools → Network, filter by “Img”, and check the “Type”/“Content-Type” column. Or use curl -I with Accept: image/avif.

What’s the fastest rollback if something goes wrong?

Disable AVIF/WebP replacement in LSCache (LiteSpeed path), or comment out the rewrite block in .htaccess/Nginx and reload the service. Purge caches after rollback.