.dev and .app domains for developers

.dev and .app are the two extensions where HTTPS isn’t a best practice — it’s enforced at the browser level. Both are run by Google Registry (through its subsidiary Charleston Road Registry), and before either TLD even opened for public registration, Google added the entire extensions to the browser HSTS preload list. That means every browser shipping that list — Chrome, Firefox, Safari, Edge — refuses to load any .dev or .app site over plain HTTP. Not just your site once you’ve configured it: every domain under these TLDs, including one registered five minutes ago with nothing behind it. That single infrastructure decision is what makes these two genuinely different from the hundreds of other new extensions, and it comes with exactly one gotcha worth knowing before you buy.

Why are .dev and .app HTTPS-only?

Google Registry launched .app in May 2018 and brought .dev to general availability in February 2019, and pitched security as the headline feature from day one. Announcing .dev, Google’s framing was that the “new domain is secure by default because it requires HTTPS to connect to all .dev websites.”

The mechanism behind that promise is HSTS preloading. Normally, HSTS (HTTP Strict Transport Security) works domain by domain: a site sends a header telling the browser “only ever talk to me over HTTPS,” and browsers remember it. The preload list goes one step further by baking that instruction into the browser itself, so even the very first visit is upgraded before any request leaves your machine. Google’s move was to put the whole of .dev and .app on that list at the TLD level, before anyone could register a name — so there is no opt-out, no configuration flag, and no way for any .dev or .app domain to serve plain HTTP to a mainstream browser.

For most other TLDs, HTTPS adoption depends on each site owner doing the right thing. Here it’s a property of the namespace. Your users get an encrypted connection or nothing.

What’s the one real gotcha?

You need a working TLS certificate before your site loads at all. Because browsers never attempt plain HTTP on these TLDs, the familiar path of “get it live on http first, sort out SSL later” doesn’t exist. Until a valid certificate is in place, visitors see a connection error rather than your site.

In practice, this splits cleanly into two cases:

• On modern hosting platforms, it’s a non-issue. Most current hosts provision and renew certificates automatically the moment you connect a custom domain, so the HTTPS requirement is satisfied before you ever think about it.
• On custom and local setups, it can bite. If you’re pointing the domain at a hand-configured server, or wiring it into a local development setup, TLS has to be part of step one rather than a finishing touch. Plan for the certificate at the same time you plan the DNS.

That’s the entire downside. If your stack already terminates TLS automatically — and in 2026, most do — the forced-HTTPS design costs you nothing and quietly guarantees something you’d want anyway.

Who should pick a .dev or .app domain?

Both TLDs are open to anyone worldwide, first-come-first-served — you don’t have to prove you’re a developer or that you’ve shipped an app. But they suit audiences who read HTTPS-by-default as a feature rather than a hurdle:

• Developer tools and APIs. A .dev address tells a technical audience what the product is before they’ve read a word, much like .io does — see how the two compare in our .com vs .io vs .ai vs .co breakdown. If you’re naming in this space, our domain ideas for developer tools guide goes deeper.
• Documentation sites. Project docs live naturally at a .dev domain, and the enforced HTTPS matches the expectations of the people reading them.
• Portfolios and personal sites. A short yourname.dev is often available where the .com equivalent is long gone.
• Side projects and products with an install or signup. .app reads naturally for anything users download, open, or log into — and both extensions tend to have far better name availability than .com.

Do .dev and .app rank worse in Google?

No. Google has been consistent for over a decade that it treats new gTLDs like any other gTLD — no penalty for the extension, and, worth noting, no ranking boost for being on a Google-run TLD either. The forced HTTPS is a browser-level security property, not a search-ranking lever. If you want the full evidence trail, see do exotic TLDs hurt SEO? — and for how .dev and .app fit into the broader wave of new extensions, our new gTLDs guide covers the landscape.

The suffix decision is the easy part; finding a name that’s actually available is where the time goes. Domain Yoga takes a plain-language description of what you’re building and returns availability-checked, brandability-ranked name ideas across .dev, .app, .com, .io, and many other extensions — so you can see your realistic options side by side before you commit.