Garbled text such as "Préférences" in place of "Préférences" means the browser read UTF-8 text with another character encoding. TermsFeed Free Cookie Consent holds its 36 translations as UTF-8 text inside its script. The browser decodes that script with the first encoding it finds, and your own inline configuration with the encoding of the page.

The browser takes the charset the server sends in the Content-Type header first. Without one, it takes the charset attribute of the script tag, and without that, the encoding of the page.

Cause 1: The page does not declare a character encoding

A page without <meta charset="utf-8"> or a server charset lets the browser guess its encoding, and a wrong guess garbles your own text and any script decoded with the page encoding. The <meta charset="utf-8"> tag on your page is the fix you control on every platform, unless the server sends the page with another charset in its Content-Type header.

Open the Console tab and run document.characterSet. Any value other than "UTF-8", such as "windows-1252", means the browser does not read your page as UTF-8.

Declare UTF-8 on the page and save your files in the same encoding.

  1. Add <meta charset="utf-8"> as the first element inside <head>, and set UTF-8 on any server that sends the page with another charset.
  2. Save your template files as UTF-8 in your editor, then publish them and clear any page cache.
  3. Reload, run document.characterSet again, and confirm that it returns "UTF-8".

Cause 2: The script tag lost charset="UTF-8"

The charset="UTF-8" attribute decides the encoding of a script that the server sends without a charset, which matters for a self-hosted copy of Cookie Consent. The generator writes charset="UTF-8" on both script tags, the loader and the inline run() script. The loader then adds the script file cookie-consent-code.js without the attribute, so that file depends on the server header or the page encoding.

www.termsfeed.com sends both Cookie Consent files with charset=utf-8, so the hosted install shows the translations correctly on any page. A self-hosted copy falls back to its charset attribute, then to the page encoding, when its server does not send a charset. A copy a page speed plugin combines into another file does the same.

Open the Network tab, select the request for your copy of the script, and read Content-Type under Response Headers. A header without a charset, on a script tag that lacks charset="UTF-8" in the page source, leaves your copy to the page encoding.

Add charset="UTF-8" to the script tag of your copy, and keep <meta charset="utf-8"> on the page. Read what changes for a copy on your own server in Self-Host Free Cookie Consent on Your Server.

Cause 3: A server sends the script with another charset

A charset in the Content-Type header the server sends with the script takes precedence over the script tag and the page, so a server that sends charset=iso-8859-1 garbles every translation. Your own server for a self-hosted copy, a proxy, or a content delivery network (CDN) that rewrites headers causes this.

Open the Network tab, type cookie-consent in the filter, reload, and select the script request. The Headers pane shows Content-Type under Response Headers, where a charset other than utf-8 points to the server, proxy, or CDN that sends the script. Set UTF-8 for JavaScript files on that server, such as AddCharset UTF-8 .js on Apache or charset utf-8; on nginx, and clear the CDN cache. The nginx charset directive applies only to the types in charset_types, whose default lists application/javascript. Where your mime.types sends .js files as text/javascript, add that type to charset_types.

Cookie Consent shows text in an unexpected language

Cookie Consent shows the language the language option sets, or without the option a language from the browser settings, then English. An option value Cookie Consent does not support, such as "ca" (Catalan is ca_es), "nb" (Norwegian is no), or "zh" (Traditional Chinese is zh_tw), gives English.

Debug mode prints [i18n] Language set from the language option as: <code> or [i18n] Language set from the browser as: <code>. Read that line to see which rule chose the language.

Set the language option on each page to the language of that page, with a code from the supported list. A language the visitor picks in the Preferences Center menu applies to the current page only. Find the 36 codes in Cookie Banner Languages.

The website name or other configuration text is garbled

The website_name you set, and every other text in your configuration, comes from your page, so it follows the page encoding. A site name such as "Café Müller" turns garbled on a page that does not declare an encoding, while the Cookie Consent translations around it stay correct.

Run document.characterSet in the Console tab. A value other than "UTF-8" points to the page encoding. With "UTF-8", check that your template file is saved as UTF-8.

Declare UTF-8 on the page with the steps for a page that does not declare an encoding. Write the characters themselves, not HTML entities. Cookie Consent shows website_name as plain text, so Caf&eacute; appears exactly as typed.

How to verify that every character shows correctly

A correct setup shows accented letters and non-Latin scripts in the consent banner and the Preferences Center in every language you use. Check the page, the script response, and 2 languages after each fix. Publish your change and clear any page cache first.

  1. Close every private window, open a new one, open DevTools with F12, and load your page.
  2. Open the Console tab, run document.characterSet, and confirm "UTF-8".
  3. Open the Network tab, type cookie-consent in the filter, and confirm that the script request shows charset=utf-8, or no charset, in its Content-Type.
  4. Open the Preferences Center, pick "German" in its language menu, and confirm that the German umlauts show correctly in both dialogs.
  5. Pick "Greek" in the same menu, and confirm that the Greek letters show correctly in both dialogs.