The gap it closes
A site can have a perfectly valid certificate and still be vulnerable to a
downgrade attack on the very first request: if a user types
example.com without specifying https://, the
browser's first request often goes out over plain HTTP by default. An
attacker positioned on the network (a malicious Wi-Fi hotspot, for
example) can intercept that first plain-HTTP request and quietly keep the
entire session on HTTP, or redirect it somewhere else entirely — the
user's browser never gets a chance to negotiate TLS at all, so there's no
certificate to warn about.
A server-side redirect from HTTP to HTTPS helps, but it still requires that first vulnerable plain-HTTP request to reach the real server safely — which is exactly the request an attacker in the middle can intercept before the redirect ever happens.
How the header works
Once a browser has received the header once over a genuine HTTPS connection:
Strict-Transport-Security: max-age=31536000; includeSubDomains
it remembers, for max-age seconds, to rewrite any future
request to that domain to HTTPS internally — before a single byte goes
out over the network. This means the vulnerable first-request scenario
above only exists for a domain's very first visit from a given browser,
never for a return visit within the max-age window.
includeSubDomains extends the same protection to every
subdomain — worth including deliberately, since a forgotten subdomain
still serving plain HTTP is a common gap otherwise.
The preload list, and its real tradeoff
The header only protects a browser that has already visited the site at least once. The HSTS preload list solves the true "first visit, ever" case: browsers ship with a hardcoded list of domains that should never be contacted over plain HTTP, checked before any network request is made at all — closing the gap completely, even for a brand-new visitor who's never been to the site before.
The tradeoff is real and worth understanding before submitting a domain: removal from the preload list is slow, taking weeks to months to propagate to already-shipped browsers, because it depends on the next browser release cycle picking up the updated list. Submitting a domain before HTTPS is reliably configured on every subdomain — including ones you might add later — can lock out plain-HTTP access to those subdomains for a long time if something isn't ready.
What HSTS doesn't do
It says nothing about certificate validity, chain trust, or which TLS versions are offered — a site can have HSTS correctly configured and still be running a deprecated TLS version, or serving an expired certificate the browser will still refuse. HSTS is specifically about preventing the protocol-downgrade attack, not a general security score.