Impact-Site-Verification: 41b53a0c-6d04-458b-a457-fe9e29acde1a

.app Was HTTPS-Mandatory Before Your First Visit — HSTS Preload Baked Into Chrome, Not a Checkbox
TLD Guides··10 min read

.app Was HTTPS-Mandatory Before Your First Visit — HSTS Preload Baked Into Chrome, Not a Checkbox

~1.2M active names, Charleston Road Registry (Google) still on Nomulus—not GoDaddy Registry—$25M ICANN auction, TLD-level HSTS since October 2017, and why the old guide's figma.app/notion.app roster, AIO boilerplate, and thin SEO paragraph failed audit.

NN

NewName Editorial

Editorial Team

Open cash.app. You land on Block's live consumer fintech product—send, receive, Bitcoin, the works. Open tech.app. In mid-2026 you are more likely to hit a parked page or a registrar upsell than a shipped app. Same suffix, opposite evidence quality. The stub this guide replaces never made that distinction. It listed figma.app, notion.app, slack.app, zoom.app as "notable users" when Figma leads with figma.com, Notion with notion.so, Slack with slack.com, and Zoom with zoom.us—defensive registrations, not primary brands. It also recycled daily-TLD SEO boilerplate ("Google treats .app as a standard generic TLD") and an AIO considerations section claiming SoftwareApplication schema earns "outsized AI citation share"—unaudited, delete-on-sight.

The story worth telling is not "mobile-first branding." It is registry-level HSTS preload: before any registrant configures headers, before any certificate exists, Chromium's built-in transport security state already treats every *.app hostname as HTTPS-only. That architectural choice—not semantic cleverness—is what makes .app different from .com.

The security contract: TLD preload, not site opt-in

Most domains earn HSTS gradually: serve a Strict-Transport-Security header, ramp max-age, submit to hstspreload.org, wait for a Chrome release. hstspreload.org's own guidance now says routine preloading is not recommended for ordinary sites—the operational burden on subdomains is too high.

.app skipped the opt-in entirely. In October 2017, Chromium commit 3054dabc added the public suffix app to transport_security_state_static.json with mode: force-https and include_subdomains: true (Chromium source). Firefox, Safari, and Edge inherit variants of the same list. The rule is compiled into browser binaries—not fetched at runtime.

What that means in practice:

  • The first navigation to http://anything.app is upgraded to HTTPS or hard-fails. There is no cleartext window for downgrade attacks.
  • Every subdomain inherits the rule—including staging.product.app, internal tools, and DNS typos you forgot about.
  • HSTS does not issue certificates. You still need TLS termination (Let's Encrypt, Cloudflare, your host's auto-cert). No cert = browser error, not a polite redirect.
  • Removal is effectively impossible at the TLD layer. Individual domains can petition hstspreload.org removal; an entire preloaded public suffix does not get rolled back because one startup misconfigured staging.

Google Registry marketed this at launch as "the first TLD with enforced security made available for general registration" (Google blog, May 2018). Sibling Google TLDs .dev, .page, .new, and others share the same preload pattern in Chromium's static file—but .app was the launch vehicle that proved the model for a mass-market namespace.

Who runs it—and what GoDaddy is not

Registry operator (2026): Charleston Road Registry Inc. (CRR), d/b/a Google Registry—a wholly owned Google LLC subsidiary, separate from Google Domains the registrar per ICANN's registry/registrar split (Google Registry FAQs). Technical stack: Nomulus on Google Cloud—open-source registry software Google uses for .app, .dev, .google, and dozens of other TLDs.

GoDaddy Registry does not operate .app. GoDaddy Registry runs backend services for ~170 other TLDs (.club, .us, .nyc, etc.) per its 2024 10-K. GoDaddy the registrar sells .app alongside .com—that is a retail channel, not registry ownership. Conflating the two leads to wrong assumptions about pricing authority and policy changes.

Acquisition economics: CRR won .app at ICANN's last-resort auction on 25 February 2015 for $25,001,000—then the highest ICANN auction price, beating 11 other applicants including Amazon and Donuts (ICANN results). Public launch followed 8 May 2018 after a seven-day Early Access Program with declining daily fees (Google launch post).

Zone size: passed .io, still a fraction of .com

| Metric | Source / date | Figure | |--------|---------------|--------| | Active domains | whois.lws.fr / ICANN MRR, April 2026 | ~1,204,850 | | YoY growth (active) | Same | +50.7% | | Total registrations (cumulative) | Instant Domain Search zone data, mid-2026 | ~1,934,676 (+37% YoY) | | vs .io | Same guide | ~214,000 more than .io's ~1.72M | | vs .dev | Same | ~728,796 on .dev (+45% YoY, smaller base) |

.app is the largest HTTPS-preloaded product TLD by volume—not the largest TLD overall. Treat zone growth as semantic fashion plus Google's eight-year marketing, not proof that every registered string hosts a product.

Pricing: standard shelf, premium tiers that never sleep

Google Registry sets wholesale via a rate card; registrars add markup (.app pricing policy). Premium names carry elevated registration and renewal fees identified before purchase—not just a one-time launch surcharge.

| Tier | Typical range (USD, mid-2026) | |------|------------------------------| | Standard new registration (1 yr) | $14–$22 | | Standard renewal (1 yr) | $16–$24 | | Transfer | $14–$22 | | Registry premium (examples) | $280–$1,000+/yr renewal on tiered dictionary words (HN registrar thread) | | Reserved / strategic release | travel.app, shop.app, health.app class—often withheld or premium (DN.org launch analysis) |

Model renewal at the tier you bought, not the promo banner. ICANN's uniform-renewal language does not stop registries from defining multiple premium renewal classes—Google categorizes names into tiers at registration time, and that tier persists.

Verified roofs—and the brochure names to delete

Skip Mad Libs (startup.app, notes.app, health.app as "notable sites" without live products). These mid-2026 checks return mission-aligned surfaces on .app itself:

cash.app — Block's consumer fintech; primary brand domain, not a redirect stub.

linear.app — Linear's product home; issue tracking SaaS at scale on .app as canonical URL.

windy.app — Weather app for wind sports; featured on get.app with a live product surface.

fellow.app — Meeting-management SaaS; primary domain per Google Registry showcase.

android.app / chrome.app — Google-owned navigational names on the registry's own TLD.

figma.com / notion.so / slack.com — Counterexamples: majors hold .app defensively (Figma even faced UDRP case D2026-0440 over figma.app) but lead with other suffixes. Holding ≠ building.

whatsapp.app — Meta defensive registration; consumer product remains whatsapp.com / app stores.

Trash the old guide's lazy equivalence between "SaaS company" and ".app mandatory." The suffix signals product identity when you choose to canonicalize there—not when you park a redirect.

What HSTS preload breaks (the ops checklist)

Before you point production DNS at .app, verify:

  1. TLS on every hostname you create—including www, api, staging, and forgotten legacy CNAMEs.
  2. Staging environments cannot "temporarily" serve HTTP on a public .app subdomain; use .localhost, .test, or an non-preloaded TLD for internal cleartext if you truly need it.
  3. Certificate automation before bulk subdomain creation; one expired cert on old-api.product.app is a hard outage, not an SEO warning.
  4. Deep links and email must use https:// schemes; some older Android WebViews and corporate proxies still mishandle preloaded suffixes—test on real devices.
  5. Parking and for-sale landers must serve valid HTTPS; most registrars handle this in 2026, but custom landers on your own nginx need certs day one.

This is the trade Google Registry made: eliminate downgrade attacks namespace-wide in exchange for zero tolerance for TLS misconfiguration.

SEO and AI search: gTLD, not a ranking cheat code

.app is a standard generic TLD in Google's systems—no geographic targeting, no special ccTLD handling. John Mueller's standing guidance applies: keywords in the TLD are not a ranking signal. Forced HTTPS removes one misconfiguration vector; it does not substitute for content, links, or technical performance.

For AI surfaces (ChatGPT Search, Perplexity, Google AI Overviews): models cite pages with authority and freshness, not suffix semantics. cash.app appears because Cash App is a known product, not because .app whispers "mobile application" to model weights. No audited AIO preference layer exists—do not bolt on schema templates expecting citation dividends.

One routing question—not a who-should matrix

Skip symmetric columns. Ask:

Are you building a public product surface where HTTPS-from-byte-zero and "this is an app" URL semantics justify staging rigidity—or buying a trendy redirect you could host cheaper on .com?

Choose .app when you ship mobile apps, PWAs, or consumer SaaS where the suffix shortens explanation in ads and app-store fallback flows, you will canonicalize marketing and download pages on .app (not just defensively register), and your team accepts TLS automation as a launch gate. Pair with defensive .com before Series A—see Domain Hacks for the linear.app / corporate-site split pattern.

Skip .app when you need HTTP-accessible legacy paths (rare but real in industrial IoT), when mainland China is core (ICP filing complexity on exotic gTLDs—keep .cn/.com.cn operational), when developer docs are the identity (→ .dev), when infra/API signal matters more than "app" (→ .io), or when you only want a cheap defensive redirect you will never promote (.com + /app path may suffice).

Alternatives worth comparing:

  • .dev — Same HSTS preload family; engineer-facing, not consumer-app semantics.
  • .page — Google sibling for landing pages; also HTTPS-preloaded.
  • .io — No TLD-level HSTS; separate Chagos sovereignty stack.
  • .ai — AI-native vanity; Anguilla ccTLD economics, not Google Nomulus.
  • .com — Institutional default; unlimited HTTP if you insist (please don't).

FAQ

Why can't I load my new .app domain over HTTP?

The entire .app public suffix is in Chromium's HSTS preload list with includeSubDomains. Browsers refuse cleartext before your site sends any headers.

Do I still need an SSL certificate?

Yes. HSTS forces HTTPS connections; TLS certificates prove identity to complete them. No cert = connection failure.

Who operates .app in 2026?

Charleston Road Registry (Google Registry) on Nomulus. GoDaddy Registry is a different operator for other TLDs; GoDaddy the registrar sells .app retail.

Is .app good for SEO?

Neutral as a gTLD. HTTPS is a baseline signal .app makes hard to violate. Rankings still follow normal quality signals—see SEO-friendly domain names.

Can I remove .app from HSTS preload?

Not as a registrant. TLD-level preload is baked into browser releases. Plan around permanent HTTPS obligation.

Premium renewal shocked me—who sets that?

Google Registry tiering at registration time. Registrars pass through the same renewal class; shop tiers before checkout.


Stress-testing app brand architecture across suffixes? Our domain search checks .app, .dev, .com, and 1,000+ extensions in one pass—or read How to Create a Memorable Brand Name before you pay premium tier renewals for a clever hack.

Related articles

All posts