Fix ERR_CONTENT_DECODING_FAILED on WordPress & cPanel

You open your site and Chrome shows a blank page with "This page isn't working" and a small line underneath: ERR_CONTENT_DECODING_FAILED. No PHP error, nothing in the log, and the site might load fine in another browser or from your phone. It's confusing, but it's one of the more predictable errors once you know what it's actually saying.

In plain words: the server told the browser "this response is compressed," and the browser couldn't unpack it. Either the compression is broken, applied twice, or announced but never actually done. Here's how to find which one you're dealing with.

Symptom: what you'll see

• Chrome/Edge: ERR_CONTENT_DECODING_FAILED ("Content Encoding Error" in Firefox).
• Usually the whole page fails, sometimes only wp-admin, a single plugin page, or one CSS/JS file.
• Often started right after enabling a caching/CDN/compression plugin, switching PHP version, or turning on Cloudflare.
• Works with curl but fails in the browser, because curl doesn't ask for compression unless you tell it to.

Cause: the usual suspects

The browser sends Accept-Encoding: gzip, br. The server replies with a Content-Encoding: gzip header and a body. If the body doesn't match that header, you get the error. These are the real-world reasons that happens:

Fix, step by step

1. Confirm it's an encoding problem

Ask for the page both ways from a terminal:

curl -sI -H "Accept-Encoding: gzip" https://yourdomain.com/ | grep -i -E "content-encoding|content-length|server"
curl -s -H "Accept-Encoding: gzip" https://yourdomain.com/ --output - | gzip -t

If gzip -t prints "not in gzip format" or "unexpected end of file" while the header says gzip, that confirms the body and header disagree. Run the same against a static file like /wp-includes/js/jquery/jquery.min.js. If that's fine and only PHP pages fail, the problem sits in PHP or a WordPress plugin, not the web server.

2. Rule out double compression in PHP

In cPanel, open MultiPHP INI Editor and check zlib.output_compression. If Apache's mod_deflate (or LiteSpeed) is already compressing, set it to Off. You can also check from a file in your account:

<?php phpinfo(); ?>

Search the output for zlib.output_compression. Delete the file when you're done, since phpinfo leaks server details.

3. Look at your .htaccess

Open public_html/.htaccess in File Manager (enable "Show Hidden Files"). If you see more than one compression block, for instance one from a caching plugin and one you added yourself, remove the duplicates:

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/css application/javascript
</IfModule>

Keep one. Also look for php_value zlib.output_compression On lines, which clash with this. If you're on PHP-FPM, php_value in .htaccess can cause 500s instead, so move it to the INI editor.

4. Hunt for stray whitespace and BOMs

This one is sneaky. If a file starts with a blank line before <?php, or ends with whitespace after ?>, those bytes go out before PHP's output buffer starts compressing. The browser sees a gzip stream with junk at the front.

Check from SSH or the cPanel terminal:

cd ~/public_html
grep -rlP '^\xEF\xBB\xBF' --include=*.php wp-config.php wp-content/themes wp-content/mu-plugins 2>/dev/null
tail -c 20 wp-config.php | xxd

Any match means a file saved with a BOM. Re-save it as "UTF-8 without BOM" in your editor. Recently edited functions.php or wp-config.php are the top candidates.

5. Disable plugins that handle compression

Caching and optimization plugins (page cache, "enable gzip", minify) are frequent offenders. Rename wp-content/plugins to plugins-off briefly. If the error disappears, rename it back and re-enable plugins one at a time. When you find the culprit, turn off its own gzip option and let the server handle compression.

Also purge the plugin's cache folder (wp-content/cache). A cached body saved with the wrong encoding will keep failing even after you fix the settings.

6. Check Cloudflare or any proxy

If you use Cloudflare, it compresses with gzip or Brotli on its own edge. Set your origin to send uncompressed or standard gzip, never both a custom encoding and a CDN rewrite. Quick test: pause Cloudflare for the domain for a few minutes (DNS tab, grey-cloud the record). If the error vanishes, purge the Cloudflare cache and look at any transform rules or Workers touching headers. On a VPS running Nginx in front of Apache, make sure only one layer has gzip on; active for the same content:

sudo nginx -T 2>/dev/null | grep -n -i gzip
sudo nginx -t && sudo systemctl reload nginx

7. Make sure the response isn't being cut off

If the compressed stream ends early, the browser complains. Check the basics:

• df -h and df -i, since a full disk or inode limit can truncate writes and cache files.
• The PHP error log in your account folder for fatal errors or memory exhaustion mid-request.
• Apache/Nginx error logs for "upstream prematurely closed connection" or timeouts.

Prevention

• Compress in one place only. Pick the web server (or the CDN), and turn off every other gzip toggle, including plugin options and zlib.output_compression.
• Edit PHP files in a UTF-8 without BOM editor. Skip the closing ?> in pure PHP files so trailing whitespace can't sneak in.
• Test after every optimization change with the curl gzip -t check above. It takes ten seconds.
• Purge caches after changing compression, headers, or PHP versions.
• Keep disk usage under control so cache and log writes don't fail mid-response.

If you've been through the list and the error still shows on a SkyServer account, send our support team the output of the two curl commands from step 1 and the affected URL. With that, we can usually tell in a couple of minutes which layer is breaking the response.

Frequently Asked Questions

Why does the site work in Firefox but not Chrome?

Browsers differ in how forgiving they are with slightly malformed streams, and they may advertise different encodings (Brotli vs gzip). A corrupted response can slip through one and fail in another. Don't rely on that; fix the stream itself.

Is ERR_CONTENT_DECODING_FAILED a problem with my computer?

Rarely. If other devices on other networks see it too, it's server-side. Clearing the browser cache or trying an incognito window is worth a quick test, but the fix is almost always on the server or CDN.

Will disabling gzip make my site slow?

Slightly larger transfers, yes, but a working uncompressed site beats a broken fast one. Once you've identified the double layer, re-enable compression in exactly one place.

Can a security plugin or WAF cause this?

Yes. Anything that rewrites responses, such as firewall plugins, ModSecurity rules or proxy filters, can alter a compressed body. Disable it briefly to test, then check its logs.

It only fails on wp-admin. Why?

Admin pages often run extra plugin code and output buffering. A plugin printing output early, or a BOM in an admin-only file, breaks compression only there. Work through the plugin and BOM steps above.