What is the irreversible commitment you make when you submit a domain to the HSTS preload list?

What is the irreversible commitment you make when you submit a domain to the HSTS preload list?

HSTS (HTTP Strict Transport Security, RFC 6797) tells browsers to refuse plaintext. Preloading bakes that rule into the browser binary, so removal can take months to propagate. Run this gate before you submit at hstspreload.org.

— Confirm every subdomain, including ones you forgot (legacy mail, status pages, intranet hosts), serves valid HTTPS. includeSubDomains applies to all of them with no exceptions.
— Serve the header on the apex over HTTPS with max-age=31536000; includeSubDomains; preload. The preload token is required and is your machine-readable consent.
— Redirect HTTP to the same host's HTTPS first (not straight to www); the checker demands the apex's own redirect chain be clean.
— Inventory third-party services on subdomains that may not support TLS; they will become unreachable, not merely warned.
— Document a rollback: removal requires a separate request and one to two release cycles to reach stable browsers.

Evidence vs. speculation: there is no fast un-preload. Treat the submission as a one-way door.

Further reading: RFC 6797 section 12.3; Chromium HSTS preload guidelines.

Bottom line: preload is a policy decision about your entire namespace, not a header tweak.