Help Centre
Getting started
Charsetlint diagnoses why a web page shows mangled characters (mojibake) by reading all three places a browser checks for character encoding and reporting which ones disagree.
How to run a diagnosis
- Go to the Diagnose page.
- Paste the full URL of the page displaying encoding problems (e.g.
https://example.com/blog/post). - Click Check encoding.
- Read the results:
- Header — the HTTP
Content-Typeresponse header's charset parameter. - BOM — whether a byte-order mark (UTF-8, UTF-16, or UTF-32) is present at the start of the response.
- Meta — the
<meta charset>tag, and its position (byte offset).
- Header — the HTTP
- A CONTRADICTION banner means at least two declarations disagree. A green “All clear” banner means they agree.
- The Issues flagged section lists specific problems found, including the classic
’mojibake pattern.
The winner badge marks the declaration the browser trusts
first in its priority order. This is usually the HTTP header → BOM →
meta tag. A mismatch happens when, for example, the header says
iso-8859-1 but the file is saved as UTF-8.
Frequently asked questions
This is the most common encoding problem Charsetlint catches. The character
’ appears when a UTF-8 encoded file is served with a
Content-Type: text/html; charset=iso-8859-1 (or
windows-1252) HTTP header. The browser reads the header, treats
the UTF-8 bytes as latin-1, and renders the wrong glyphs.
E2 80 99. Interpreted as latin-1, those three bytes become
â (E2), € (80), ™ (99) — which renders as “’”.
Fix: Change the server's Content-Type header
to text/html; charset=utf-8. How you do that depends on your
server software (Apache .htaccess, Nginx config, or your
hosting control panel). Charsetlint tells you which declaration is wrong
— it does not fix it for you.
<meta charset="utf-8"> — why doesn’t it work?
The HTTP Content-Type header outranks the
<meta charset> tag in browser priority order. If your
server sends Content-Type: text/html; charset=iso-8859-1 in
the HTTP response, the browser uses that value even if your HTML declares
utf-8 in the meta tag.
This is the exact reason Charsetlint exists: you check your own file, see the meta tag is correct, and cannot find the problem — because the problem is in a response header you may not control directly. Run the URL through Charsetlint to see what the header actually says.
No. Charsetlint is a diagnostic tool only. It reads and reports the three encoding declarations, flags contradictions, and identifies mojibake patterns. It does not convert file encodings, re-encode content, modify your server configuration, or generate corrected files.
Think of it as a lint tool for charset declarations, not a repair service. Once you know which declaration is wrong, you fix it at the source (server config, framework settings, or HTML).
The diagnostic runtime that fetches URLs cannot reach hosts behind Cloudflare’s edge network (including example.com, cloudflare.com, 1.1.1.1, stackoverflow.com, and many others). Those hosts report as unreachable. This is a platform limitation of the runtime environment, not a result about the target server.
If your own site is behind Cloudflare, you may need to check the encoding declarations from server-side logs or a local tool. The diagnosis page always shows the error message when this limitation applies.
No. Each diagnosis is completely ephemeral. The URL you submit, the HTTP response headers, and the first 4096 bytes of the response body exist only in memory for the duration of the request. No database, cache, or log retains any record. The results displayed in your browser are held in local memory only and disappear when you close or reload the page.
See the privacy policy for full details.
The Free plan provides everything available today: single-URL diagnosis covering the HTTP header, BOM, and meta tag, contradiction detection, and mojibake issue flagging.
The Pro plan ($9/month) will add API access with authentication, batch scanning for multiple URLs, and higher rate limits (100 req/min). These features are planned but not yet built. No payment processor is connected, so the Pro plan cannot be purchased at this time.
See the pricing page for current status.
Known limitations
Charsetlint is honest about what it cannot do. The following are current limitations of the service:
- No file conversion or re-encoding. Charsetlint diagnoses encoding declarations but does not convert, fix, or re-encode files. It is a linter, not a repair tool.
- Cloudflare-hosted URLs. Hosts behind Cloudflare’s edge network are unreachable from the diagnostic runtime. This is a platform limitation, not a result about the target server.
-
Meta charset beyond byte 1024. Browsers only scan the
first 1024 bytes for a
<meta charset>declaration. If your meta tag appears later in the document, it is invisible to parsers. Charsetlint flags this when it detects the tag past the scan limit. - No API yet. Programmatic access via API is planned for the Pro plan but has not been built.
- No batch scanning. Each request diagnoses one URL. Batch scanning for multiple URLs is planned but not implemented.
- No saved reports or history. Every diagnosis is ephemeral. Report history is planned for the Pro plan but not built.
- No payment processing. A Stripe account has not been wired to the service. Pro subscriptions cannot be purchased. Prices are listed for reference only.
Contact
For now, the best way to get help is to run a diagnosis and read the results carefully. The diagnosis page itself explains each declaration, flags specific issues, and tells you which declaration wins the browser priority order. Most encoding problems are self-diagnosable once you see the contradiction.
If you believe you have found a bug in Charsetlint itself (rather than an encoding problem on your own site), the owner needs to establish a bug-reporting channel before one can be offered here.