Charset Declared.

Performance Best Practices

Missing charset can cause text rendering issues across browsers

What does this check test?

This check verifies that the HTML document declares its character encoding, either via a `<meta charset="utf-8">` tag in the `<head>` or via the `Content-Type` HTTP header with a charset parameter (e.g., `Content-Type: text/html; charset=utf-8`). The charset declaration must appear within the first 1024 bytes of the HTML document. Without a declared charset, browsers must guess the encoding, which can lead to mojibake (garbled text), rendering delays while the browser auto-detects the encoding, and potential security vulnerabilities related to encoding-based XSS attacks.

Why does it matter?

When the browser does not know the character encoding, it must scan the document to guess — this auto-detection process delays rendering because the browser cannot safely parse the HTML until the encoding is determined. Incorrect encoding guesses cause text to render as garbled characters (mojibake), which is especially problematic for sites serving non-ASCII characters (accented letters, CJK characters, emoji). Encoding ambiguity can also be exploited for XSS attacks in older browsers where encoding confusion allows script injection. UTF-8 is the universal standard that supports all languages and characters — there is no reason to use any other encoding for new websites.

Who is affected?

All websites should declare their character encoding. Sites serving multilingual content, sites with user-generated content that may contain special characters, sites migrated from older systems that used legacy encodings (ISO-8859-1, Windows-1252, Shift_JIS), and sites with dynamically generated HTML where the charset header may not be set consistently are most at risk of encoding issues.

Where does this apply?

Check the HTML `<head>` section for a `<meta charset>` tag — it should be the first element inside `<head>`, before any other tags that contain text. Also check the `Content-Type` HTTP response header for a charset parameter. In Chrome DevTools, the 'Encoding' shown in the Network panel's Response Headers should match the declared charset. If the response header and meta tag disagree, the response header takes precedence.

How to fix it

Add `<meta charset="utf-8">` as the first element inside `<head>` and set the charset in HTTP headers. Declare charset in HTML (must be first element in head):

html

<head>
  <meta charset="utf-8" />
  <title>Page Title</title>
</head>

Set charset in Nginx:

nginx

server {
  charset utf-8;
}

Ensure your source files are actually saved in UTF-8 encoding — most modern editors default to UTF-8, but legacy files may use other encodings. If migrating from a legacy encoding, convert files with `iconv`: `iconv -f ISO-8859-1 -t UTF-8 old.html > new.html`. Verify that your database connection also uses UTF-8 (e.g., `?charset=utf8mb4` in MySQL connection strings) to prevent encoding mismatches in dynamic content.

References

AppVet checks Charset Declared automatically

Run a free performance scan and get a full report with actionable fixes, including a Fix with AI prompt you can paste into any coding tool.

Run Audit

← All checks