<meta charset="utf-8"> vs <meta http-equiv="Content-Type">

Question

In order to define charset for HTML5 Doctype, which notation should I use?

1. Short:

   <meta charset="utf-8" /> 
   

2. Long:

   <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
   

Fugitive

Using a <meta> tag for something like content-type and encoding is highly ironic, since without knowing those things, you couldn't parse the file to get the value of the meta tag. – Joli

You can parse it as ASCII until you reach it. The HTML5 parsing algorithm takes this into account. – Libbylibeccio

Noted should be that neither is been used for parsing when the page is served over web. Instead, the one in HTTP Content-Type response header will be used. The meta tag is only used when the page is loaded from local disk file system. – Sheeree

The meta element is used over HTTP under certain conditions (including an absence of the data being in the HTTP header) – Libbylibeccio

If your HTML files are destined for Kindle e-books, you'll need to use the http-equiv version. – Exclamation

It is also ironic that it is named charset, when it really is for specifying an encoding. (the charset is Unicode, the encoding is UTF-8) – Preoccupied

Although its not required for HTML5, it's more an XHTML thing, Consider closing the elements, ie <meta .... />. Avoids lots of warnings in certain editors for elements that are not Void elements (<BR> etc). – Hobnailed

@Quentin: And if, for some strange reason, you want to encode your page in UTF-16 or UTF-32? I agree with Mark, the concept of using encoded data to describe its own encoding is silly, though we can usually get away with it here. But I think it's there partially because the server ultimately will have the same problem, unless the server has some other means of identifying/enforcing encoding. – Sakti

Using the long declaration for XHTML 1.0 strict works as expected. – Salverform

Best practice is for the meta charset tag to be the first tag in the head per joelonsoftware.com/articles/Unicode.html and code.google.com/p/doctype-mirror/wiki/MetaCharsetAttribute. Basically, it needs to appear in the first 512 bytes, as early as possible, then the document will be parsed with the correct encoding. – Skitter

@Libbylibeccio Exactly. That's why the content-type element is required to be within the first 100 bytes of the document. – Inductile

as of php 5.4.22 DOMDocument does not get the long one :( – Treacherous

Is there any harm in specifying both Content-Type: text/html; charset="utf-8" as an HTTP Header and having a meta tag on page (ie: <meta charset="utf-8" />)? I don't know if my hosting company adds the HTTP Header to specify UTF-8 and I have the meta tag on my pages. Didn't know if both was any issue – Alternant

The very best thing to do, would actually be to ignore all this headers, meta-tags nonsense and use the Unicode BOM. The unicode BOM is standardized at the lowest possible level, the Unicode spec itself and should therefore work everywhere instead of just in (X)HTML or over HTTP. It would work for scripts, stylesheets, text/plain documents, over HTTP, TCP, mail, you name it. The only problem is that some legacy software chokes on the BOM... But... If we all just start to use it we force the vendors to fix it. – Effluent

@StijndeWitt: And how, exactly, will the Unicode BOM help you if you need to support other encodings, such as ISO-XXX, or Japanese encodings? Also, while the BOM is standardized, the standard actually advises against using a BOM with UTF-8; see e.g. the answer to What's different between UTF-8 and UTF-8 without BOM?. – Samsun

@Samsun I think the standard's authors felt, at the time they wrote that faq, that using UTF-8 without BOM would give the best interoperability with old software, because it would match ASCII. But we are over a decade further now and UTF8 support is virtually ubiquitous. I stand by my comment that the BOM is the best place to store the encoding, because it survives over network, file systems and even databases. I still add HTTP headers and even a meta tag though. – Effluent

utf-8 does not have a BOM: As there is only one byte order (no big/little endien); because ascii is utf-8, and the BOM is not ascii. This will break pages that are just ascii. Some systems use ascii/utf-8 and adding a bom will break some old software). These systems have built on the old to produce a very good and robust system, with no need to through out the old, every time a new feature is added. – Paleethnology

UTF-8 does have a BOM. It's purpose is not to determine byte order but it serves the dual purpose to establish that the encoding used is UTF-8. "UTF-8 can contain a BOM. However, it makes no difference as to the endianness of the byte stream. UTF-8 always has the same byte order. An initial BOM is only used as a signature — an indication that an otherwise unmarked text file is in UTF-8." unicode.org/faq/utf_bom.html#bom5 – Effluent

Also, do note that ASCII is a subset of UTF-8, but the reverse is obviously not true. So if your text only contains ASCII, leave out the BOM (making it effectively ASCII). As soon as your text may contain non-ASCII characters, backward compatibility is broken anyway and you should add a BOM. – Effluent

One reason HTML files have an encoding even though supposedly http is supposed to specify the encoding is the majority of users don't have control of their servers. Rather than the boil the ocean solution of requiring every server to somehow allow users to specify an encoding for every file served it became clear that users needed a way to specify the encoding in the file itself. As for bom in utf-8 tons of software fails with it even in 2019. Whether or not there is some engineering ideal the pragmatic solutions are charset in HTML file, no bom ever for utf-8 for any file ever. – Bethink

Answer 1

In HTML5, they are equivalent. Use the shorter one, as it is easier to remember and type. Browser support is fine since it was designed for backwards compatibility.

Libbylibeccio

What about browser support? Does <meta charset='utf-8'> work in IE6? – Theologue

Here is an updated link for the Google Code page that @Šime Vidas mentioned. It says, regarding IE 6, 7, and 8, "In non-IE browsers, you can use document.characterSet. In IE, you might think you could document.getElementsByTagName('meta')[0].charset, but this only returns the character encoding you specified, not the encoding that IE is actually using." – Haymaker

I know this thread is old, but gtmetrix.com/specify-a-character-set-early.html indicates using <meta> to set the character encoding disables the lookahead downloader in IE8, which can impact your page load times. Yeah, yeah, I know... drop IE8. @MészárosLajos can come back here in a couple of years and bust our balls for still supporting IE8. ;-) – Eagan

developer.mozilla.org/en-US/docs/Web/Guide/HTML/… was a nice confirmation of this answer for me. – Shebashebang

Today I had an issue where Korean symbols weren't appearing in IE11. Dropping the short syntax in favour of the longer syntax fixed the issue. I don't know if this is due to some kind of server config though or if it is an issue with IE11 and the charset. The exact symbol combination it was failing on was 베라. – Corked

Out with the old in with the new. Demand change for the better. It is easier does the same thing and if your living in a cave with old technology... TOO BAD! Demand change for the better. – Smilax

I have found that Chrome prefers the "Long" form and Firefox prefers the "Short" form, and their preferences are mutually exclusive. I found this with UTF-8 inside SVG. The "Long" form on an HTML5 doctype didn't work in Firefox, and the "Short" form on an HTML5 doctype didn't work in Chrome, I had to use both to get both browsers to work. – Westland

And today I stumbled upon excel spreadsheet generated from template with short syntax being broken if generated on linux server, local windows machine did well. Changing for long syntax fixed encoding in output file – Fibster

Why charset in meta tag important?, where it is used?, or what is the advantage of charset in html – Overwhelm

When in doubt, I would generally go for the simpler option. But since people are reporting problems with each option, why not just have both? – Inexistent

Use the longer one when parsing the doc on the server side or serving it for servers as these are often outdated. – Treacherous

Answer 2

Both forms of the meta charset declaration are equivalent and should work the same across browsers. But, there are a few things you need to remember when declaring your web files character-set as UTF-8:

1. Save your file(s) in UTF-8 encoding without the byte-order mark (BOM).
2. Declare the encoding in your HTML files using meta charset (like above).
3. Your web server must serve your files, declaring the UTF-8 encoding in the Content-Type HTTP header.

Apache servers are configured to serve files in ISO-8859-1 by default, so you need to add the following line to your .htaccess file:

AddDefaultCharset UTF-8

This will configure Apache to serve your files declaring UTF-8 encoding in the Content-Type response header, but your files must be saved in UTF-8 (without BOM) to begin with.

Notepad cannot save your files in UTF-8 without the BOM. A free editor that can is Notepad++. On the program menu bar, select "Encoding > Encode in UTF-8 without BOM". You can also open files and re-save them in UTF-8 using "Encoding > Convert to UTF-8 without BOM".

More on the Byte Order Mark (BOM) at Wikipedia.

Imbibition

@Imbibition I would amend your answer to say "You should save...without BOM." The following page says "...it is usually best for interoperability to omit the BOM..." indicating a best practice, but not a requirement: w3.org/International/questions/qa-byte-order-mark – Onlybegotten

In IIS you can set the charset in HTTP headers with <globalization fileEncoding="utf-8" responseEncoding="utf-8"/> in Web.Config - add it to <system.web> – Avrilavrit

I just spent 30 mins trying to figure out why your charset tip was not working for me. You may have to rename default.html to index.html (or another file name). It seems Apache is hard set on certain defaults when it comes to default.html! – Sniff

as I understand things, it doesn't matter AT ALL if you save with our without BOM. – Inclinatory

Honestly, I'd always prefer an easy to configure webserver over something like apache. @Dabbu – Converse

Thanks! These info's helpful me as I'm developing my live html/css/js code editor (liveditor.com). The last time I tried the php parser (.dll) have issue processing file's in UTF8 with BOM - it outputs the BOM bytes! I don't understand why it can't detect the BOM... – Cliftonclim

The BOM does make a difference in certain contexts. It is needed when dealing with UTF-16 because RFC 2781, section 4.3, says the default encoding is big-endian, but since Windows uses little-endian by default, most software will use LE as well. To avoid any wrong interpretation of the content, the BOM comes very handy. It can be harmful in certain conditions as well, as when using PHP, the interpreter sometimes outputs the BOM and gives you errors when you try to output some HTTP Header. Summing up: don't use BOM for UTF-8; don't forget BOM for UTF-16. – Lobeline

Why do you say UTF-8 HTML should be without a BOM. Having a BOM should work fine. Also, you don't need meta and an HTTP header. You just need one of BOM, meta or HTTP header. – Kane

How do you get Visual Studio to stop being evil and always adding a UTF-8 BOM? For Tomcat you must also add URIEncoding="utf-8" to each connector. – Fecund

You specify the HTML content-type, why do you use meta charset for that? I think it's redundant., right? – Novice

@Richard one issue with using the header only is that the encoding will be lost if a user saves the html file to disk. Using the meta tag only is okay, but it makes the browser do a bit of extra parsing. So I think using both should be considered a best practice, despite the redundancy. – Veronaveronese

Why do you say UTF-8 HTML should be without a BOM Indeed, the absence of the BOM is the very reason you would need an HTTP header or meta tag in the first place. – Effluent

Summing up: don't use BOM for UTF-8 I can't agree with this. The BOM in UTF-8 is very useful for signaling the encoding type. Otherwise we have to guess, or use things like the meta tags this question refers to. The cool thing about the BOM is that it is part of the Unicode spec and thus can be used for all data encoded in Unicode, not just HTML. What we should do is use BOMs everywhere, let legacy software blow up on it, report those bugs and get them fixed. – Effluent

@StijndeWitt Not to reignite a holy war over BOM, but just a word of caution: in many cases, the BOM is often invisible to, or otherwise often overlooked by other developers. This can lead to issues if you don't explicitly bring it up to your team. One example is when serving files (such as via PHP and Apache), the BOM in a file may immediately begin the data stream, overriding any server script config/include/header lines that you mean to be parsed before transmitting any data. – Scincoid

The IETF recommends that if a protocol either (a) always uses UTF-8, or (b) has some other way to indicate what encoding is being used, then it "SHOULD forbid use of U+FEFF as a signature (see datatracker.ietf.org/doc/html/rfc3629#section-6). And therefore I use "<meta charset="utf-8" />" and not the BOM. – Fraser

Answer 3

Another reason to go with the short one is that it matches other instances where you might specify a character set in markup. For example:

<script type="javascript" charset="UTF-8" src="/script.js"></script>

<p><a charset="UTF-8" href="http://example.com/">Example Site</a></p>

Consistency helps to reduce errors and make code more readable.

Note that the charset attribute is case-insensitive. You can use UTF-8 or utf-8, however UTF-8 is clearer, more readable, more accurate.

Also, there is absolutely no reason at all to use any value other than UTF-8 in the meta charset attribute or page header. UTF-8 is the default encoding for Web documents since HTML4 in 1999 and the only practical way to make modern Web pages.

Also you should not use HTML entities in UTF-8. Characters like the copyright symbol should be typed directly. The only entities you should use are for the five reserved markup characters: less than, greater than, ampersand, prime, double prime.

Entities need an HTML parser, which you may not always want to use going forward. They introduce errors, make your code less readable, increase your file sizes, and sometimes decode incorrectly in various browsers depending on which entities you used. Learn how to type/insert copyright, trademark, open quote, close quote, apostrophe, em dash, en dash, bullet, Euro, and any other characters you encounter in your content, and use those actual characters in your code.

The Mac has a Character Viewer that you can turn on in the Keyboard System Preference, and you can find and then drag and drop the characters you need, or use the matching Keyboard Viewer to see which keys to type. For example, trademark is Option + 2. UTF-8 contains all of the characters and symbols from every written human language.

So there is no excuse for using -- instead of an em dash. It is not a bad idea to learn the rules of punctuation and typography also ... for example, knowing that a period goes inside a close quote, not outside.

Using a <meta> tag for something like content-type and encoding is highly ironic, since without knowing those things, you couldn't parse the file to get the value of the meta tag.

No, that is not true. The browser starts out parsing the file as the browser's default encoding, either UTF-8 or ISO-8859-1. Since US-ASCII is a subset of both ISO-8859-1 and UTF-8, the browser can read <html><head> just fine either way ... it is the same. When the browser encounters the meta charset tag, if the encoding is different than what the browser is already using, the browser reloads the page in the specified encoding.

That is why we put the meta charset tag at the top, right after the head tag, before anything else, even the title. That way you can use UTF-8 characters in your title.

You must save your file(s) in UTF-8 encoding without BOM

That is not strictly true. If you only have US-ASCII characters in your document, you can Save it as US-ASCII and serve it as UTF-8, because it is a subset. But if there are Unicode characters, you are correct, you must Save as UTF-8 without BOM.

If you want a good text editor that will save your files in UTF-8, I recommend Notepad++.

On the Mac, use Bare Bones TextWrangler (free) from Mac App Store, or Bare Bones BBEdit which is at Mac App Store for $39.99 ... very cheap for such a great tool.

In either app, there is a menu at the bottom of the document window where you specify the document encoding and you can easily choose "UTF-8 no BOM". And of course you can set that as the default for new documents in Preferences.

But if your Webserver serves the encoding in the HTTP header, which is recommended, both [meta tags] are needless.

That is incorrect. You should of course set the encoding in the HTTP header, but you should also set it in the meta charset attribute so that the page can be saved by the user, out of the browser onto local storage and then opened again later, in which case the only indication of the encoding that will be present is the meta charset attribute.

You should also set a base tag for the same reason ... on the server, the base tag is unnecessary, but when opened from local storage, the base tag enables the page to work as if it is on the server, with all the assets in place and so on, no broken links.

AddDefaultCharset UTF-8

Or you can just change the encoding of particular file types like so:

AddType text/html;charset=utf-8 html

A tip for serving both UTF-8 and Latin-1 (ISO-8859-1) files is to give the UTF-8 files a "text" extension and Latin-1 files "txt."

AddType text/plain;charset=iso-8859-1 txt
AddType text/plain;charset=utf-8 text

Finally, consider saving your documents with Unix line endings, not legacy DOS or (classic) Mac line endings, which don't help and may hurt, especially down the line as we get further and further from those legacy systems.

An HTML document with valid HTML5, UTF-8 encoding, and Unix line endings is a job well done. You can share and edit and store and read and recover and rely on that document in many contexts. It's lingua franca. It's digital paper.

Hardwood

"If you only have ISO-8859-1 characters in your document, you can Save it as ISO-8859-1 and serve it as UTF-8, because it is a subset" - incorrect. It would be correct if you change "ISO-8859-1" to "US-ASCII". US-ASCII is compatible with UTF-8 because it is a subset, ISO-8859-1 is not. To convert ISO-8859-1 (containing non-ASCII characters) to UTF-8, you would need to encode the non-ASCII characters. The code points for ISO-8859-1 do exist in Unicode, but UTF-8 encodes the ones outside of US-ASCII differently to ISO-8859-1. – Sievers

Your point about HTML entities is good. In the past, I've used entities only to find that they were converted to their UTF-8 characters after being saved on different systems and/or opened in different editors. It's worth noting, however, that non-breaking spaces (&nbsp;) can produce confusing results since you typically won't see them in your editor so are usually best to keep as entities for clarity's sake (in my experience). – Sidetrack

"You should also set a base tag..." should come with the caveats described here. – Hurtado

Another reason you might prefer HTML entities is if you're using something like ionicons. I'd rather see  than the default glyph, or some strange character I don't recognize. – Veronaveronese

Answer 4

<meta charset="utf-8"> was introduced with/for HTML5.

As mentioned in the documentation, both are valid. However, <meta charset="utf-8"> is only for HTML5 (and easier to type/remember).

In due time, the old style is bound to become deprecated in the near future. I'd stick to the new <meta charset="utf-8">.

There's only one way, but up. In tech's case, that's phasing out the old (really, REALLY fast)

Documentation: HTML meta charset Attribute—W3Schools

Trypanosomiasis

Regarding the link, please see meta.https://mcmap.net/q/41734/-bring-windows-mobile-6-forms-into-the-front – Perreault

Answer 5

While not contesting the other answers, I think the following is worthy of mentioning.

1. The “long” (http-equiv) notation and the “short” one are equal. Whichever comes first wins;
2. Web server headers will override all the <meta> tags;
3. BOM (byte order mark) will override everything, and in many cases it will affect HTML 4 (and probably other stuff, too);
4. If you don't declare any encoding, you will probably get your text in “fallback text encoding” that is defined your browser. Neither in Firefox nor in Chrome it's UTF-8;
5. In absence of other clues the browser will attempt to read your document as if it was in ASCII to get the encoding, so you can't use any weird encodings (UTF-16 with BOM should do, though);
6. While the specifications say that the encoding declaration must be within the first 512 bytes of the document, most browsers will try reading more than that.

You can test by running echo 'HTTP/1.1 200 OK\r\nContent-type: text/html; charset=windows-1251\r\n\r\n\xef\xbb\xbf<!DOCTYPE html><html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><meta charset="windows-1251"><title>привет</title></head><body>привет</body></html>' | nc -lp 4500 and pointing your browser at localhost:4500. (Of course you will want to change or remove parts. The BOM part is \xef\xbb\xbf. Be wary of the encoding of your shell.)

Please mind that it's very important that you explicitly declare the encoding. Letting browsers guess can lead to security issues.

Graduated

Good points, but can you detail which security issues are you referring to? – Deniable

The long notation shouldn't override the short one—simply the first one in the document should win. – Saracen

@Deniable In the past there used to be problems with UTF-7 from what I remember. Also sniffing on the web is generally bad, e.g. when you upload an image something which is sniffed as script content. – Perpetual

@Saracen tested in chrome and firefox, you're right. edited the answer accordingly. Armfoot: it was something about some 7 bit encoding, don't remember what exactly. – Graduated

"Neither in Firefox nor in Chrome it's utf-8" — What do you mean? If not utf-8, what is it then? – Selfsatisfaction

@CraigMcQueen pretty sure the browser fallback still (in 2018) defaults to Western European in Western Europe, so I imagine it defaults to whatever pre-unicode encoding has been dominant in each region. Users can set the fallback to utf-8 but this just exposes all the crappy encoding thousands of sites still use as glitchy high byte ascii characters all over, so it is still not common. More's the pity. Can't see how this is going to change without a little coercion from the browser vendors, and they're not keen on breaking legacy stuff. – Prince

Answer 6

Use <meta charset="utf-8" /> for web browsers when using HTML5.

Use <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> when using HTML4 or XHTML, or for outdated DOM parsers, like DOMDocument in PHP 5.3.

Treacherous

Answer 7

To embed a signature in an email, I would use the long version:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

The reason is that not many email readers use HTML5, so it's always better use old HTML styles. Actually, it's better to use tables than divs + CSS as well.

Blayze

Answer 8

There is some news based on Mozilla Foundation, and SitePoint:

Do not use this value (http-equiv=content-type) as it is obsolete. Prefer the charset attribute on the <meta> element.

Halberd

oh finally, something a bit more recent – Sociolinguistics

The XHTML1 standard says otherwise, don't fall for the Mozilla-only view on things - they don't even explain their note. Whoever dealt with XML (to understand XHTML) should know it comes with an encoding parameter right away. – Aseptic

Turns out the warning is not the mozilla foundation website anymore? – Cull