The Expect-CT header let a website tell visiting browsers to enforce Certificate Transparency compliance for its certificates, and optionally report violations to a specified URL. Chrome deprecated it in version 107 in late 2022, and it's now considered obsolete — worth understanding both for what it did and for what made it unnecessary.
What it did while it was active
Expect-CT: max-age=86400, enforce, report-uri="https://example.com/ct-report"A site sending this header was asking the browser to exactly verify that any certificate served for that domain appeared in public CT logs, refusing the connection (with enforce set) if it didn't, and optionally sending a report to the specified URL if a violation occurred. It functioned as an opt-in enforcement and monitoring mechanism, similar in spirit to how HSTS lets a site opt into strict HTTPS enforcement.
Why it became unnecessary
The header existed in particular because, at the time, CT compliance wasn't yet a universal requirement — some certificates weren't logged, and browsers weren't uniformly checking. That changed: publicly trusted CAs are now required to log every certificate they issue, and current certificates carry embedded proof of that logging (Signed Certificate Timestamps) in the certificate itself. With CT enforcement now baked into how a certificate is validated by default, a site-configured header opting into a check that already happens unconditionally serves no remaining purpose.
If you still see this header in a scan or warning
Tools like Google PageSpeed Insights and Chrome DevTools will flag an Expect-CT header if they find one still being sent, because it's a deprecated API with no remaining effect — not because it causes an active problem. The header is simply ignored by current Chrome versions. If you find it in your own configuration (commonly left over from an older security-headers plugin or a copied configuration template), removing it is a safe, purely cleanup-oriented change with no functional downside.
What replaced it, functionally
Nothing needed to replace it — CT enforcement itself didn't go away, only the optional opt-in header did, because the enforcement it requested became unconditional. If you're precisely interested in monitoring for a misissued certificate against your own domain, our dedicated CT Log Search tool and the broader Certificate Transparency guide cover the current, still-relevant way to in practice watch for that.
A useful example of a security mechanism's natural lifecycle
Expect-CT's rise and removal is a clean, well-documented example of a genuinely common pattern in web security: an opt-in mechanism serves as a bridge while an ecosystem transitions toward universal enforcement, and once that transition completes, the opt-in mechanism itself becomes redundant. HPKP (HTTP Public Key Pinning) followed a similar, if more troubled, path — introduced, found to carry more risk than benefit in practice, and ultimately removed from browsers entirely rather than just deprecated.