.app Domain Review: HSTS, Mobile, and the Default-HTTPS TLD

.app launched in 2018 with one structural feature no other major TLD had: every .app domain has been HSTS-preloaded since day one, meaning browsers refuse to load any of them over plain HTTP. Google, which runs the registry, framed it as a "secure by default" TLD. Eight years later, that decision turns out to be the most interesting thing about it — and the reason .app has carved out a sustainable niche where many gTLDs from the same launch wave didn't.

The short version

.app is the right pick for consumer mobile and web apps where the buyer knows the word "app." It's a worse pick for B2B SaaS, infrastructure, or anything that talks to engineers. Pricing is sane, registry is professional, and the HSTS thing is a real (if invisible) feature.

Why HSTS preloading mattered

Most TLDs ask each domain to opt into HSTS individually. .app opted in for everybody at the registry level. The practical effects:

No mixed-content footguns. You can't accidentally serve a .app site over HTTP. Browsers won't let users through.
No HTTPS-misconfiguration phishing. A .app site that doesn't have a valid cert just doesn't load. Phishers can't lazy-misconfigure.
A small but real trust signal in security-aware audiences. Engineers and security folks know about the HSTS preloading; consumers don't, but the second-order effect (no .app ever loads insecurely) is something they experience without naming.

Eight years in, it's clear the registry-level HSTS hasn't been a marketing slogan it's been a real defensible feature.

Where .app actually works

Consumer mobile apps with a marketing site. When the audience already knows what an "app" is and you want a domain that just says "this is the app's home," .app reads as exactly that.
Cross-platform apps. When the same product is iOS + Android + web, .app is the cleanest way to say "this is the platform-agnostic landing page." It's also short.
Standalone web apps that aren't B2B SaaS. Side projects, hobbyist tools, indie maker stuff — .app is the right weight class.
PWAs and mobile-first products. Anything that's been built mobile-first has a natural fit here.

Where .app underperforms

B2B SaaS. Buyers in B2B don't think of the product as an "app." They think of it as a platform, a tool, a system, a workflow. .app reads consumer to enterprise buyers.
Infrastructure and devtools. Engineers default to .io or .dev for these. .app reads as the product layer above infrastructure, not as the infrastructure itself.
AI products. .ai has eaten this segment. There's no reason to fight that with a .app unless the product is genuinely consumer-mobile-first.
Premium one-word names. The dictionary .app market is real but priced aggressively; for many of these, the equivalent .com (where reachable) still does more work for the brand.

Pricing patterns we see

.app has settled into surprisingly reasonable pricing for an alt TLD with a real audience:

Single-word dictionary .app: $10K–$80K for general words, more for category-defining ones ("draw", "note", "track"). Stable for ~3 years.
Two-word brandable .app: $500–$5K. The wide market. Quality of the second word matters more than the TLD.
Three-letter .app: $2K–$15K, with pronounceable LLLs commanding the premium.

Renewal pricing is in line with other modern gTLDs ($15–$25/yr at retail), with no signs of the kind of registry-driven pricing shock that .io had in 2024.

How the audience reads .app

There's a distinct audience perception split between technical and non-technical viewers:

Non-technical readers parse .app as "the app" — a shortened version of "application." This is the read you want: it's simple, it's accurate, it's already in their vocabulary.
Technical readers parse .app as "this is a Google TLD with HSTS." This isn't bad, but it's a slightly more loaded read than the non-technical case.

The asymmetry is why .app works well for consumer products and less well for technical products. The latter audience has more context to project onto the TLD; the former just reads it literally and moves on.

How we score .app names

Six dimensions, with two .app-specific notes:

Mobile-app-style names score higher than abstract ones. .app rewards names that sound like apps you'd download — verbs, action words, short product names. Abstract or corporate names underperform on the same TLD.
HSTS doesn't show up in the score, but it shows up in due diligence. Buyers occasionally ask whether HSTS preloading affects deliverability for email, certificate-renewal automation, etc. The honest answer is: in 2026, this is solved everywhere; assume it's a non-issue.

Should you buy a .app today?

For a consumer mobile product where the .com is unreachable: yes, especially if the name reads naturally as a noun referring to the app itself.

For B2B SaaS or developer tools: probably not. .com, .io, or .ai will do more work depending on your category.

If you're holding a .app and want to know what it'd actually clear at, send it in for an appraisal. We look at the second-level word, the audience read, and the comp data on similar names — same as we'd do for any TLD review.