How to ensure the page uses a UTF-8 charset declaration?

charset-not-utf8 page

The issue

A page that doesn’t declare UTF-8 can show visitors garbled text: accented letters, curly quotes and non-Latin scripts turn into replacement symbols. The same garbling can reach a search engine’s index and the snippet it shows.

The cause is that the browser has to know how to turn bytes into characters. Without a declaration it guesses from the HTTP header or from the bytes themselves, and a wrong guess changes every character outside ASCII.

Scope

Each HTML response declares its own encoding. Probeo reads the <meta charset> element in the page’s HTML. A page that declares UTF-8 only in its Content-Type header, or through <meta http-equiv>, is still reported, because the meta tag is what keeps the declaration with the file.

How to check you have it

  • In probeo: the page reports Missing or non-UTF-8 <meta charset>; expected <meta charset="utf-8">.
  • By hand: view the page source and look near the top of <head> for <meta charset="utf-8">. Run curl -sI <url> and read the Content-Type header, which should say charset=utf-8 if it names a charset at all.
  • With a tool: the W3C Markup Validation Service reports a missing or conflicting encoding declaration.

The fix

Add <meta charset="utf-8"> as the first element in the page’s <head>.

The HTML standard requires the declaration within the first 1024 bytes of the document, so it goes before the title, scripts and styles. If the server sends a Content-Type header with a charset, make it utf-8 as well, so the two agree. The file itself must be saved as UTF-8; the declaration describes the bytes, it doesn’t convert them.

Done when: every page declares <meta charset="utf-8"> early in <head>, any Content-Type charset agrees, and the check above comes back clean.

Do not

  • Do not leave the encoding for the browser to infer.
  • Do not declare a legacy encoding without a specific technical reason.
  • Do not place the meta charset tag after other content in <head>.
  • Do not let the HTTP header and the meta tag name different encodings.

FAQ

What happens if the HTTP header declares a different charset than the HTML meta tag?

The header wins. Browsers use a byte order mark first, then the Content-Type charset, then the meta tag. The page then renders differently from what the file says, so make the two agree.

Is UTF-8 required even if the page contains only ASCII characters?

It is still worth declaring. Content changes, and the first curly quote or accented name added later will render wrongly if the browser has guessed a different encoding. ASCII is valid UTF-8, so the declaration costs nothing.

Where should the meta charset tag appear in the HTML head?

First. The HTML standard requires it within the first 1024 bytes, and putting it before anything else keeps it there as the head grows.

Can the charset declaration be omitted if the server sends a Content-Type header with charset=utf-8?

Browsers will render the page correctly from the header. The meta tag still matters when the file is saved, cached or served by something that drops the header. Probeo reports the page either way, since it reads the meta tag.

What encoding should be used if the page is not UTF-8?

UTF-8. Legacy encodings such as ISO-8859-1 or Windows-1252 cover only a subset of characters. Converting the file to UTF-8 and declaring it removes the problem rather than describing it.

Does the charset declaration affect how search engines rank the page?

Not as a ranking signal. A wrong encoding garbles the text that gets indexed, which affects what queries the page can match and what its snippet says.

Which product detects this

Probeo checks this on every page of your site as part of Site Clarity. This page explains one instance; the product tells you every page that has it.