cPanel MIME Types: Fix Fonts, Video & Files That Won't Load

A font shows up as boxes, a video downloads instead of playing, or your PWA manifest just won't register — and everything looks fine when you open the file directly. This is almost always a MIME type problem, not a broken file. Here's how to spot it and fix it in cPanel without breaking anything else.

Symptom: what a MIME type problem actually looks like

MIME type issues rarely announce themselves clearly. They usually show up as one of these:

• Custom web fonts fall back to a default typeface, and DevTools shows an error like OTS parsing error: invalid version tag or was not loaded because its MIME type ('text/html') is not a supported stylesheet MIME type.
• An .mp4 or .webm video prompts a download instead of playing inline, or the player just shows a black box.
• A manifest.json or .webmanifest file loads fine in the browser address bar, but Chrome won't offer the "Add to Home Screen" prompt for your PWA.
• A JavaScript module (.mjs) or WebAssembly file (.wasm) fails with Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of "text/plain".
• An API endpoint or fetch() call that should return JSON gets parsed as plain text, and response.json() throws.

The common thread: the file itself is fine, but the server is telling the browser it's something else — or nothing at all.

Cause: why the server sends the wrong Content-Type

A handful of things typically cause this on cPanel-hosted sites:

• Apache doesn't know the extension. Newer file types like .woff2, .webmanifest, .mjs, and .wasm aren't always in the default MIME type map, especially on older EasyApache builds. Without an explicit mapping, Apache guesses — badly, or falls back to text/plain / text/html.
• A stale or over-broad .htaccess rule from a security plugin or an old migration is intercepting requests for certain extensions before they reach the real file.
• ModSecurity is quietly blocking the request and returning a generic error page. Because that error page is served as text/html, the browser reports it as a MIME type mismatch even though the real problem is a 403 in disguise.
• A CDN or proxy (Cloudflare, etc.) cached the wrong header from before you fixed the server-side config, so the fix looks like it "didn't work" even though the origin is correct now.
• The PHP handler changed after a PHP version switch in cPanel and dropped a custom type mapping that lived in the old config.

Fix: confirm it, then correct it

Step 1 — Confirm the actual Content-Type being sent

Don't guess. Check the real header with curl:

curl -I https://yourdomain.com/assets/fonts/icon.woff2

Look at the Content-Type line in the response. If it says text/html, text/plain, or application/octet-stream where you expected font/woff2, you've confirmed the problem — and ruled out a caching illusion, since curl bypasses your browser cache.

Step 2 — Add the missing MIME type mapping

If your cPanel theme has an Advanced > MIME Types tool, you can add the mapping there directly against the domain. If it's not available (many modern cPanel themes have folded it elsewhere or removed it), add it via .htaccess in your site's document root instead:

<IfModule mod_mime.c>
    AddType font/woff2                  .woff2
    AddType font/woff                   .woff
    AddType application/manifest+json   .webmanifest
    AddType application/javascript      .mjs
    AddType application/wasm            .wasm
    AddType video/mp4                   .mp4
    AddType video/webm                  .webm
</IfModule>

These take effect immediately — .htaccess is re-read on every request, so there's no service to restart for this step.

Step 3 — Check for a rule that's blocking the request entirely

If curl -I returns a 403 or the body of the response (add -v or drop the -I) looks like an error page rather than your file, the real issue is ModSecurity or a bad rewrite rule, not a missing MIME type. In cPanel, check Security > ModSecurity and look for recently triggered rules against that path. On a VPS with WHM access, the audit log is usually at:

/usr/local/apache/logs/modsec_audit.log

If you find a rule ID hitting your asset path, disable it for that specific path rather than turning ModSecurity off site-wide.

Step 4 — Purge CDN/proxy cache after the fix

If you're on Cloudflare or another CDN, purge the cache for the affected file paths (or do a full cache purge for smaller sites) after correcting the header. Otherwise the edge will keep serving the old, wrong Content-Type for however long the cache TTL is set, and the fix will look broken even though it isn't.

Common extensions and the MIME types they need

Prevention

• When you add a modern JS build pipeline (Vite, esbuild, a PWA setup) to a site, add the newer extensions to .htaccess proactively instead of waiting for something to break.
• Avoid blanket "deny by file extension" rules in .htaccess or security plugins that don't get updated when you introduce new asset types.
• After any EasyApache rebuild or PHP version change, spot-check a font, a video, and a JSON endpoint with curl -I before you call the migration done.
• Keep a copy of a known-good .htaccess before editing it, so a bad rule is a one-line revert instead of a rebuild.