Character Encoding (Charset) Checker
Character encoding decides which letters the bytes on your page stand for. Declare it wrongly, or not at all, and accented text falls apart: "güzel" turns into "güzel" and "şirket" into "ÅŸirket". This tool audits your encoding at three levels: is it declared, is it in the right place and the right form, and, most importantly, are there still broken characters in the page's text?
Checking the declaration isn't enough, you have to check the result
Most charset checkers find a charset tag on the page and call it a day. But the majority of broken characters come not from a wrong declaration but from content that was saved broken in the first place. If the text was once written into the database in the wrong encoding, it will keep looking broken no matter what your page declares. That's why this tool scans the page text alongside the declaration and counts the signature sequences of broken encoding (ü, ş, İ, ’ and the like). If the declaration is right but the text is broken, the problem lies in the content, in the database connection's encoding, or in an import/export step.
The 1024-byte rule
The HTML specification requires the character encoding declaration to be COMPLETE within the document's first 1024 bytes. The reason is simple: the browser reads the document from the start and can't parse it without knowing the encoding. If the declaration comes late, the browser begins with a guess; when the guess is wrong it has to abandon parsing and start over. That means both wasted work and a risk of mangled characters. Note that the limit is measured in BYTES, not characters: long comments in the <head>, inline style blocks or a pile of meta tags burn through the budget fast. The right place is immediately after <head> opens.
Order of precedence: BOM, HTTP header, then meta
Encoding can be declared in three separate places, and when they clash the order is fixed. At the top sits the byte order mark (BOM) at the start of the file. Below it comes the HTTP Content-Type header sent by the server. At the bottom sits the meta tag on the page. That order is the source of a very common confusion: a developer sees a UTF-8 tag in the source, but if the server declares something else the browser listens to the server and the tag does nothing at all. This tool compares the two declarations and, when they conflict, tells you which one is actually applied.
Why UTF-8?
Legacy encodings such as ISO-8859-1, ISO-8859-9 or windows-1254 can carry the letters of a particular language perfectly well. Their coverage stops there, though: emoji, mathematical symbols, quotations in other alphabets and a great many typographic characters simply can't be represented. UTF-8 carries all of it in one encoding, and it is the web's common ground today. One thing to watch when moving from a legacy encoding to UTF-8: changing only the tag doesn't fix the text, it breaks it. The content itself has to be re-encoded too.
How does mojibake happen?
The bytes don't get corrupted; what breaks is the rule used to read them. The most common pattern is text written as UTF-8 being read as Latin-1. In UTF-8 the letter "ü" is two bytes; read one at a time as Latin-1 letters, those two bytes appear on screen as "ü". Likewise "ş" becomes "ÅŸ", "İ" becomes "Ä°" and a curly apostrophe becomes "’". Those traces also tell you where the problem is: if it only shows in text coming from the database, suspect the connection encoding; if only on certain pages, the file encoding those pages were saved in; if everywhere, the server declaration.
Your Questions
Frequently Asked Questions
Where should the charset tag go?
Immediately after <head> opens, ideally on the first line. The declaration must complete within the document's first 1024 bytes, and long comments or inline styles in the <head> can eat that budget and push the tag past the limit.
If the HTTP header has a charset, do I still need the meta tag?
Technically no, the browser listens to the header. Adding it is still recommended: the declaration disappears if the page is saved as a file and opened locally, or if the header is lost at an intermediate layer. It's one line of insurance. Just make sure both declare the SAME value.
My page says UTF-8 but accented characters are still broken. Why?
The declaration may be right while the content was saved broken. If the text was once written into the database in the wrong encoding, declaring UTF-8 on the page won't repair it. The second possibility is that the HTTP header declares a different encoding and overrides your meta tag. This tool distinguishes the two: if it counts broken sequences in the text, the problem is in the content; if it reports a conflict, the problem is in the declaration.
I'm on a legacy encoding. Should I move to UTF-8?
Yes, but migrate carefully. Changing only the tag breaks the existing text; the content has to be re-encoded as well. The database, the table and column character sets, the connection encoding, the encoding of the template files themselves and the server header all need handling together. After the migration you can use this tool to confirm no broken sequences remain in the text.
Is a BOM harmful?
Not to the browser; on the contrary, it settles the encoding definitively and sits at the top of the precedence order. Problems appear on the server side: in some languages the BOM leaks into the start of the output as an invisible character and causes errors like "headers already sent" or unexpected whitespace at the top of the page. Saving your files as UTF-8 without a BOM is the common preference.
Does this tool check my whole site?
No, it audits the single page you enter. Encoding problems are usually site-wide, but they can also be local to particular pieces of content coming out of the database. To scan every page, use our Deep Crawl tool.