In a document's `<head>`, what can `<meta http-equiv="…">` actually deliver, and how does it differ from sending the same directive as an HTTP response header?

## What `http-equiv` was for A `<meta>` element carries document metadata. With `name`/`content` it declares information about the page; with `http-equiv`/`content` it declares a *pragma directive* — historically "an HTTP header equivalent", from an era when authors publishing static files could not configure their server. Browsers never implemented that generally. Today only a closed set of pragmas has any effect, and everything else is inert markup. ## The pragmas that actually work - **`content-type`** — declares the character encoding. In modern HTML the shorthand `<meta charset="utf-8">` is the form you write; the pragma form `<meta http-equiv="content-type" content="text/html; charset=utf-8">` means the same thing. A real `Content-Type` response header carrying a charset wins over the document's declaration. - **`refresh`** — reloads or redirects after a delay: `<meta http-equiv="refresh" content="5; url=/next">`. It works, but it is user-hostile — it moves the user without warning and cannot be paused, which is why timing-related accessibility criteria push back on it. A server redirect is better for the redirect case, and a user-triggered action is better for the rest. - **`default-style`** — selects which alternate stylesheet set is preferred. Rarely used. - **`content-security-policy`** — genuinely enforced by browsers. This is the one meaningful security pragma, and it has real limits (below). - **`x-ua-compatible`** — the legacy `IE=edge` incantation that told old Internet Explorer which rendering engine to use. Inert in every current browser; if you find it in a template, it is history, not policy. ```html <meta charset="utf-8"> <meta http-equiv="content-security-policy" content="default-src 'self'"> ``` ## The ones people believe in that do nothing - **`X-Frame-Options`** — ignored in a meta tag. Browsers honour it only as a response header. A page "protected" by `<meta http-equiv="X-Frame-Options" content="DENY">` is fully framable. This is the single most common mistake in this area. - **`Set-Cookie`** — no longer honoured; setting cookies from markup was removed. - **`Strict-Transport-Security`**, **`Access-Control-Allow-Origin`**, cache-control directives, and the rest of the header vocabulary — all inert as meta tags. A `<meta http-equiv="Cache-Control" content="no-store">` does not control any cache that matters. The rule of thumb worth carrying: if you cannot name the pragma on the honoured list, assume the meta form does nothing and check. ## Two structural reasons headers are stronger **Timing.** A response header is available before the parser starts on the body. A meta pragma exists inside the byte stream, so it only takes effect once the parser reaches it — after anything above it in the document has already been seen, and after the browser's preload scanner may have started fetching subresources. This is the same reason encoding declarations must appear early: content parsed under the wrong assumption has to be re-decoded, and content already requested under no policy was requested without one. **Scope.** The meta form of CSP deliberately drops directives that must be known before the document exists or that govern the document's relationship to its embedder: `frame-ancestors`, `report-uri`/`report-to`, and `sandbox` are ignored when the policy arrives via meta. That is not an oversight — a policy that decides whether the page may be framed at all cannot sensibly be delivered *inside* the page that has already been framed and parsed. So framing control, violation reporting and sandboxing are header-only, by design. ## A related tag that is not `http-equiv` Referrer policy is often lumped in here, but it is a `name`, not a pragma: `<meta name="referrer" content="strict-origin-when-cross-origin">`. This one *is* honoured, and it is the markup counterpart of the `Referrer-Policy` header. It shares the timing caveat — requests issued before the parser reaches it are unaffected — so put it high in the head or send the header instead. ## How to answer this in an interview Say what the mechanism is (a fixed list of pragmas, not a general header channel), name what is honoured and what is not, and give the two structural reasons — timing and scope — that make headers authoritative. Then give the practical posture: configure the header at the server or edge as the source of truth, and use a meta pragma only where you genuinely cannot, accepting that it arrives late and cannot express the framing and reporting directives.