Character Encoding Checker
Check where a page declares its encoding, whether the declarations agree, and whether they arrive in time.
About this tool
Reports every place a page declares its character encoding — HTTP header, meta tag, byte order mark — says which one a browser will actually use, and checks the declarations agree.
They do not always. The HTTP header overrides the meta tag, so a page with `charset=utf-8` in the markup and `ISO-8859-1` in the header renders as mojibake while the HTML looks entirely correct. That combination is a server default nobody changed, and it is invisible from the source.
The other rule with a hard edge: **the declaration must appear inside the first 1024 bytes** of the document. Past that the browser has already begun guessing, and a meta tag pushed down by a long block of inline script arrives after the decision was made.
The page is also scanned for the replacement character, which is what a mis-decoded byte turns into and the most direct evidence that something has already gone wrong.
Common questions
Which declaration wins?
A byte order mark first, then the HTTP Content-Type header, then the meta tag. This surprises people: fixing the meta tag while the server sends a different header changes nothing at all.
Why must the meta tag be in the first 1024 bytes?
Because the browser has to decide how to decode the document before it can finish reading it. It looks in that window, and if nothing is there it starts guessing. A tag further down arrives after the decision.
Should I use a byte order mark?
No. It is unnecessary for UTF-8 and causes real problems: PHP files with one emit those bytes before any output, which breaks headers and adds stray whitespace at the top of the page.
What does the replacement character mean?
A question mark in a diamond means a byte was decoded with the wrong encoding and could not be represented. It is direct evidence of a mismatch, and it is usually accented letters written as UTF-8 and read as Latin-1.