Start here
Before you fix it: what this check means
Scavo checks the declared text encoding in the HTML and response headers for missing or conflicting values, so letters and symbols can be interpreted as intended. Scavo inspects charset declarations from three places.
Why this matters in practice: checking the reported setting helps you keep the site working as intended.
Use this as evidence, not a final verdict. This result covers what the scan could observe at that time, not every page or visitor situation. Check the live site first. Open the published page and ask your developer to inspect the reported request or setting Make one controlled change. Emit `<meta charset="utf-8">` near the top of `<head>`. Re-scan the same URL and compare the finding; check the feature yourself as well.
Background sources
TL;DR: Your pages don't declare a character encoding, causing browsers to guess — which can mangle special characters and accented text.
Without a declared charset, browsers use heuristics to guess the encoding. This frequently garbles accented characters (é becomes é), em dashes, curly quotes, and any non-ASCII text. For multilingual sites, this is catastrophic. The fix is one meta tag: <meta charset="UTF-8"> before any other content in the head.
What Scavo checks (quick version)
Scavo inspects charset declarations from three places:
<meta charset="..."><meta http-equiv="content-type" content="...; charset=...">- HTTP
Content-Typeresponse header
Exact logic:
Warning: no charset declaration found.Warning: multiple different charsets are declared.Warning: one charset declared but it is not UTF-8/utf8.Pass: a single UTF-8 declaration is detected.
Scavo stores detected charsets and header values in check details.
How Scavo scores this check
Scavo assigns one result state for this check on the tested page:
- Pass: baseline signals for this check were found.
- Warning: partial coverage or risk signals were found and should be reviewed.
- Fail: required signals were missing or risky behavior was confirmed.
- Info: Scavo could not gather enough reliable evidence on this run to score pass/fail confidently.
In your scan report, this appears under What failed / What needs attention / What is working for charset, followed by Recommended next steps and Technical evidence (for developers) when needed.
- Scan key:
charset - Category:
TECHNICAL
Why fixing this matters
Wrong or inconsistent encoding causes garbled characters, broken punctuation, and data-quality issues in forms/content.
UTF-8 is the web default for modern multilingual content and avoids most compatibility issues.
Common reasons this check warns
- Old template includes legacy
iso-8859-1declaration. - Header middleware sets a different charset from HTML meta.
- Multiple plugins inject duplicate meta charset tags.
- API/edge responses miss explicit content-type charset.
If you are not technical
- Ask your developer to standardize responses to UTF-8.
- Request proof from both source HTML and response headers.
- Check pages with special characters (accented text, symbols).
- Re-run scan after fix.
Technical handoff message
Copy and share this with your developer.
Scavo flagged Character encoding (charset). Please make charset declarations consistent and UTF-8 across HTML meta and HTTP headers for this URL. Remove conflicting declarations and re-run the scan.If you are technical
- Emit
<meta charset="utf-8">near the top of<head>. - Ensure
Content-Typeheaders include UTF-8 where applicable. - Remove duplicate or conflicting charset declarations.
- Confirm templating/layout partials cannot inject legacy charset values.
Example
<meta charset="utf-8">How to verify
- Check page source for one UTF-8 declaration.
- Check headers with
curl -Iand inspectContent-Type. - Validate non-ASCII text renders correctly on key pages.
- Re-run Scavo and confirm
Pass.
What this scan cannot confirm
- It does not decode raw bytes to prove payload encoding correctness.
- It does not validate every static asset type.
- It does not guarantee all downstream integrations preserve UTF-8.
Owner checklist
- [ ] Assign one owner for response header/content defaults.
- [ ] Standardize charset handling in base layout and middleware.
- [ ] Add regression test for charset output on key templates.
- [ ] Re-check encoding after framework/server upgrades.
FAQ
Why can conflicting charset declarations break pages?
Browsers may prioritize one declaration over another, producing unpredictable decoding outcomes.
Is UTF-8 always the right choice for modern web pages?
In almost all cases, yes. HTML guidance and platform defaults strongly favor UTF-8.
Do we need both meta charset and header charset?
One clear declaration can be enough, but many teams keep both aligned for robustness across delivery paths.
Can CDN changes introduce charset issues?
Yes. Header rewrite rules can unintentionally override origin charset values.
Sources
- MDN:
<meta>element reference - MDN: Content-Type header
- WHATWG Encoding Standard
- WHATWG HTML: character encodings and declarations
Need help tracing charset conflicts across app, CDN, and server layers? Send support one failing URL and raw response headers.
