Die Kennzeichnung der Sprache beliebiger Teile eines HTML-Dokuments geschieht in der gleichen Form, wie bei XML, also durch Angabe eines lang-Attributs, allerdings ohne Angabe des XML-Namespaces (xml:lang) (siehe Abschnitt 2.3, „Sprachbestimmung“).

Für die Angabe der Kodierung eines HTML-Dokumentes fehlt eine solche einfache Möglichkeit. Sie lässt sich nur über einen Umweg bewerkstelligen, über das Attribut http-equiv des meta-Elements:

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

Mit dem Attribut lassen sich also beliebige HTTP-Header „emulieren“. Welche Bedeutung hat dies aber konkret?

Der HTML-Standard ([HTML-4.01]) sieht eigentlich vor, dass der Web-Server diese Meta-Information auswertet und zur Erzeugung von HTTP-Headern verwendet. In der Praxis lassen die Web-Server (der Apache verhält sich jedenfalls so) genau dies jedoch aus gutem Grunde sein, weil es bedeuten würde, dass jedes Dokument vor der Auslieferung durch den Server nach den entsprechenden Meta-Informationen durchsucht werden müsste, was sich wiederum sehr negativ auf die Performance auswirkt.

Tatsächlich werten die Clients, also die Browser, die Informationen aus, und Autoren „missbrauchen“ das Attribut dazu, fehlende Server-Informationen zu ergänzen oder zu überschreiben. Das zeigt aber auch das grundsätzliche Problem dieser Technik auf, weil es nämlich keineswegs klar ist, wie widersprüchliche Informationen zu interpretieren sind, wenn beispielsweise der Server behauptet, ein Dokument wäre in UTF-8 kodiert, während das Dokument selber die Angabe ISO-8859-1 macht.

Ein solcher Zustand lässt sich relativ einfach herbeiführen, wenn man nur etwas vorschnell entsprechende Konfigurationsdirektiven (zum Beispiel AddDefaultCharset oder DefaultCharset) in die Server-Konfiguration einfügt. Dieser Fehler liegt aber wenigstens noch im eigenen Verantwortungsbereich und lässt sich auch dort beheben. Gefährlicher sind schon die Schwierigkeiten, die sich bei Zwischenschaltung eines Proxy-Servers ergeben können, wenn das Dokument also über mehrere Stationen ausgeliefert wird. Ein Proxy-Server hat durchaus das Recht, Dokumente on the fly bei der Auslieferung zu konvertieren. Geht der Proxy beispielsweise davon aus (weil das Attribut charset im Header Content-Type fehlt), dass ein Dokument in ISO-8859-1 kodiert ist, tatsächlich ist es aber in KOI8-R kodiert, und wandelt der Proxy es unter dieser (falschen) Annahme in UTF-8 um, kommt das Dokument in unlesbarer Form beim Browser an.

Das beschriebene Verhalten des Proxy-Servers wäre völlig legal, aber natürlich nicht wünschenswert. In der Praxis wird man solche Fehler dadurch zu vermeiden versuchen, dass man den eigenen Web-Server sorgfältig konfiguriert, insbesondere also sicherstellt, dass alle notwendigen HTTP-Header mitgeliefert werden, und so zwischengeschaltete Proxy-Server nach Möglichkeit davon abhält, solche automatischen Umwandlungen durchzuführen.

In homogenen Umgebungen ist dies bei entsprechender Planung sicher immer möglich, in heterogenen Umgebungen aber mit einigen Schwierigkeiten verbunden. Ein Horrorszenario bietet sich in dieser Hinsicht zum Beispiel den Administratoren von Universitäts-Servern. Hier hat man es oft mit einer Vielzahl von eigenverantwortlich erstellten, sprich nach eigenem Gutdünken erzeugten Dokumenten zu tun, an eine einheitliche Namenskonvention ist nicht zu denken, eine korrekte Server-Konfiguration ist damit schlechterdings unmöglich. Einziger Ausweg ist hier der Einsatz eines leistungsfähigen Content-Management-Systems, das die notwendige Homogenität sicherstellt, und dennoch das wünschenswerte Maß an Gestaltungsfreiheit bietet. Glücklicherweise gibt es da ja schon ein gutes ... ;-)

In der Praxis hat es sich bewährt, in dieser Hinsicht nach dem Grundsatz „doppelt gemoppelt ...“ vorzugehen. Einerseits sollte man durch die entsprechende Serverkonfiguration die korrekte Kennzeichnung des Contents sicherstellen, andererseits schadet es aber auch nicht, über http-equiv noch eins draufzulegen, und bei Manipulation des Contents auf dem Übertragungsweg zum Browser zumindest darauf zu hoffen, dass der die Informationen, die direkt aus dem Dokument gewonnen werden, mit Vorrang behandelt.

XHTML (siehe dazu [XHTML-1.0]) ist eine Neuformulierung von HTML in XML, gültige XHTML-Dokumente sind also auch stets gültige XML-Dokumente (aber natürlich nicht umgekehrt). Gültige XHTML-Dokumente sind - von Details abgesehen - aber auch gültiges HTML. Insofern gilt das für HTML gesagte weitgehend analog.

Was die Dokumentkodierung angibt, ergibt sich bei XHTML aus dem Erfordernis der XML-Konformität natürlich, dass das Dokument in dieser Hinsicht dem XML-Standard genügt, also entweder in UTF-8 kodiert ist, oder eine abweichende Kodierung im Attribut encoding der XML-Deklaration entsprechend angegeben ist. Ältere Browser werden die XML-Deklaration jedoch als sogenannte Processing Instruction ignorieren, und bekommen von der Kodierung also auch nichts mit. Daraus ergibt sich dann allerdings die Notwendigkeit, die Kodierung zusätzlich mit den konventionellen Mitteln von HTML und HTTP anzugeben.

Für die Sprache empfiehlt das W3C die Angabe von zwei Attributen, sowohl von lang (für ältere Clients) und xml:lang, wobei das Attribut mit Namespace-Angabe Vorrang genießt.