Help Centre

Last updated: August 21, 2026

Getting started

Charsetlint is a diagnostic tool that tells you which character encoding a browser will actually use to render your page — and whether the three places it looks disagree.

  1. Go to the tool

    Visit the Check a URL page. No account or sign-up required.

  2. Paste a URL

    Enter any HTTP or HTTPS URL into the input field. The tool fetches the page server-side, so you can check any publicly accessible URL regardless of your browser's same-origin policy.

  3. Read the report

    You get a verdict — which declaration wins — and all three declarations shown side by side: the HTTP Content-Type header, any byte-order mark (BOM), and the <meta charset> tag. If there's a contradiction, the tool names it. If mojibake is likely, it flags the specific pattern.

  4. Fix the mismatch

    Whichever declaration won but contradicts the others is usually the one you need to change. See the FAQ below for common fixes.

Frequently asked questions

Why does my page show ’ instead of an apostrophe?

This is the most common character-encoding bug on the web. The character ' (U+2019, right single quotation mark) is encoded as the two-byte UTF-8 sequence 0xE2 0x80 0x99. When a browser interprets those bytes as ISO-8859-1 (also called Latin-1), it renders them as the three characters ’.

Charsetlint flags two specific patterns that produce this exact mojibake:

  • UTF-8 bytes served as Latin-1 — the page source uses UTF-8 but the server sends Content-Type: text/html; charset=iso-8859-1 (or no charset at all, which defaults to Latin-1 on many servers).
  • Meta charset after byte 1024 — the <meta charset> tag appears too late in the document. The browser's HTML parser stops looking for a charset declaration after the first 1024 bytes and falls back to what the server sent (or its default).

Quick fix: Make sure your server sends Content-Type: text/html; charset=utf-8 and your <meta charset="utf-8"> appears within the first 1024 bytes — ideally in the first ~100 bytes, inside <head>.

How do I fix an encoding contradiction?

The fix depends on which declaration is contradicting the winner. The HTML5 spec determines priority (highest to lowest):

  1. HTTP Content-Type header — always wins if it declares a charset.
  2. Byte-order mark (BOM) — wins if present and no header charset is declared.
  3. <meta charset> — wins only if the header has no charset and there is no BOM.

If the header contradicts the meta tag: The header wins. Update your server configuration to send Content-Type: text/html; charset=utf-8 (or whatever encoding your HTML actually uses). How to do this depends on your server:
Apache: AddDefaultCharset utf-8 or AddType text/html; charset=utf-8 .html
Nginx: add_header Content-Type text/html; charset=utf-8;
Cloudflare Pages: Set the content-type via the dashboard or a _headers file.

If the BOM contradicts the meta tag: Save the file without the BOM. Most modern editors (VS Code, Sublime, IntelliJ) have a "Save with encoding" option — choose "UTF-8 without BOM".

If the meta tag is past byte 1024: Move the <meta charset> declaration to the very beginning of <head>, before any <title> or <script> elements.

What does Charsetlint actually check?

Charsetlint reports the character encoding declared in each of the three places a browser checks, in the order it checks them:

  • HTTP Content-Type response header — the definitive source per the HTML5 spec.
  • Byte-order mark (BOM) — the first 1-3 bytes of the file. A UTF-8 BOM is EF BB BF; UTF-16 and UTF-32 BOMs are detected too.
  • <meta charset> tag — scanned in the first 4096 bytes of the document.

The tool then tells you which declaration wins (per spec), identifies any contradictions between them, and flags any mojibake-indicating patterns it finds. It does not convert files, re-encode content, or perform bulk scans.

Does Charsetlint store the URLs I check? Is my page content retained?

No. Charsetlint is entirely stateless. Each request works like this:

  1. Your URL is sent to the server.
  2. The server fetches the page, reads the relevant bytes for encoding detection, generates a report.
  3. The report is returned to your browser.
  4. Nothing — not your URL, not the fetched content, not the diagnostic result — is stored, logged, or retained server-side after the response is delivered.

See our Privacy policy for the full details.

Why can't I check a Cloudflare-hosted URL?

Charsetlint itself runs on Cloudflare Workers. Cloudflare's platform refuses to open a connection back into its own network — a standard anti-looping measure. If your site is fronted by Cloudflare, the worker gets a network error and cannot complete the check.

Workaround: Test with a URL that is not Cloudflare-hosted. Good examples: https://github.com, https://wikipedia.org, any non-Cloudflare host. Also, if you can check your page via a staging or development URL that does not go through Cloudflare, that will work.

Can I use Charsetlint in my CI/CD pipeline or script it?

Not yet. The tool is currently a single-page web application with no public API. API access (with a key for automated checks) is a planned Pro feature. There is no ETA for its availability.

Known limitations

Charsetlint is in active development. Here is what the current version cannot do — or can only partially do:

Contact us

Support is not yet reachable by email.

Charsetlint does not have a mailbox, contact form, or phone line configured. The business operator has not yet registered a legal entity or set up a contact method — these are noted in the terms of service as items requiring owner action.

For now, the best path is to consult this Help Centre. The FAQ above covers the most common encoding issues, including how to fix a mismatch. If you have a problem that these pages do not address, your question will help the operator decide which contact method to set up first.

This is an honest statement of the current state. A contact channel will be added once the operator establishes one — recorded as a requirement in the project's tracking.