The .dev TLD Is Here — and It's HTTPS-Only by Design

After years of sitting in Google's registry vault, the .dev top-level domain is finally opening to the public this month — early access is running right now, and general availability lands on February 28. Developers have been eyeing this TLD for ages, and the land rush is about to begin.

But .dev ships with a property that catches a lot of people off guard: the entire TLD is on the HSTS preload list. Every .dev domain, from the moment it exists, is HTTPS-only in every major browser. There is no "we'll add the certificate later" phase. If you're planning to grab a .dev domain — and even if you're not — this is a good moment to understand what HSTS preloading actually is, because it's quietly becoming the way the web's security floor gets raised.

What HSTS actually does

HTTP Strict Transport Security is a response header that tells a browser: never talk to this site over plain HTTP again. Once a browser has seen it, every future request to that domain gets upgraded to HTTPS before it ever leaves the machine — no insecure redirect hop, no window for a network attacker to intercept.

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

The pieces:

• max-age — how long (in seconds) the browser should remember the rule. A year is the conventional minimum for a serious deployment.
• includeSubDomains — apply the rule to every subdomain too, not just the exact host that served the header.
• preload — a signal that you consent to being baked into browsers (more on that in a second).

HSTS closes the classic downgrade window: without it, a user who types yoursite.com into the address bar makes a plain-HTTP request first, and anyone on the network path — the coffee-shop Wi-Fi, a compromised router — can intercept that request before your redirect to HTTPS ever happens.

Preloading — HSTS before the first visit

The header has one structural weakness: the browser has to see it once before it protects anything. That very first visit still goes out over plain HTTP. It's a small window, but "small window" is exactly the kind of phrase attackers like.

Preloading closes it. Browsers ship with a hardcoded list of domains — maintained through hstspreload.org and consumed by Chrome, Firefox, Safari, and Edge — that are HTTPS-only from the factory. A preloaded domain never gets a plain-HTTP request from a modern browser, ever, including the first one from a brand-new device.

You can check any domain's status, and submit your own, at hstspreload.org. The requirements are strict by design:

• A valid certificate — obviously.
• Redirect from HTTP to HTTPS on the same host, if you listen on port 80 at all.
• All subdomains served over HTTPS — including that forgotten intranet. record.
• The header itself with max-age of at least one year, includeSubDomains, and the preload directive.

The commitment it implies

Read that subdomain requirement again, because it's where preloading bites. Submitting your domain is close to a one-way door — removal from the list is possible but takes months to propagate through browser releases. Once you're in:

• Every subdomain must speak HTTPS, forever. That includes the ancient vendor-hosted status page on a CNAME, the mail host with a self-signed certificate, and whatever dev.internal.yoursite.com is.
• A certificate mistake becomes a hard outage. Without HSTS, an expired certificate shows users a scary interstitial they can (unwisely) click through. With HSTS, the browser shows an error page with no bypass button. Expired cert on a preloaded domain means the site is simply unreachable.

That's not an argument against preloading — it's an argument for treating it as a commitment you instrument. Preload when your whole domain is genuinely HTTPS-clean, and put monitoring on certificate expiry the same day, because the failure mode changed from "warning" to "wall."

An entire TLD on the list

Here's what Google did that's genuinely clever: instead of individual domains, they added whole TLDs to the preload list. .app went first in May 2018 — the first TLD where HTTPS wasn't best practice but a technical requirement. .page followed late last year. And now .dev joins them, just as it opens to the public.

The result: buy example.dev, and it is preloaded before you've configured a single DNS record. You cannot serve it over plain HTTP to any modern browser. The security decision was made at the registry, and it's not negotiable — which, honestly, is how it should work. Nobody launching a site in 2019 should be making the HTTPS decision from scratch.

The Chrome 63 backstory — a warning from local dev

There's a reason many developers already know .dev is HTTPS-only, and it's a painful one. For years, .dev was a popular fake TLD for local environments — myproject.dev in /etc/hosts, or auto-configured by tools like the old Pow server on macOS. It always technically belonged to Google, but it wasn't live, so nothing broke.

Then Chrome 63 shipped in December 2017 and began enforcing HSTS preloading for .dev — and thousands of local setups died overnight, with Chrome refusing to load http://myproject.dev and no way to click through. The fix was to migrate local environments to .test or .localhost, the TLDs actually reserved for that purpose.

The lesson generalizes: TLDs you don't own can start resolving — and start carrying policy — at any time. Use reserved names for local work, and treat the public DNS as someone else's namespace.

Launching HTTPS-only from day one

Whether or not you buy a .dev domain, its constraint is worth adopting voluntarily: build as if plain HTTP doesn't exist.

• Get certificates automated from the start. Let's Encrypt makes them free, and ACME clients make renewal a solved problem — a 90-day certificate on autopilot beats a 2-year certificate on a calendar reminder.
• Test the strict path. Verify your site works with HTTPS only — no mixed content, no http:// asset URLs hardcoded in templates, secure cookies flagged as such.
• Verify the header is actually reaching browsers:

curl -sI https://example.dev | grep -i strict-transport-security
# Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

• Then monitor it like the hard dependency it is. On an HSTS-preloaded domain, your certificate is your uptime.

Where CompleteStatus fits

An HTTPS-only domain collapses two failure modes into one: certificate trouble is no longer a warning users might click past — it's a full outage. CompleteStatus monitors SSL certificate expiry and validity alongside uptime checks in one dashboard, and alerts you weeks before an expiry date instead of the morning after. If you're grabbing a .dev domain this month, create a free account and put a monitor on it the same day you point DNS — on this TLD, there's no such thing as "we'll sort out HTTPS later."