.app domain names

What .app is

.app is short for application. IANA classifies it as a generic top-level domain: open, unsponsored, and a product of ICANN's 2012 New gTLD Program. It is operated by Charleston Road Registry Inc., the registry subsidiary Google runs publicly as Google Registry, with the IANA delegation record last updated in April 2025. The string was delegated on 2 July 2015 and reached general availability on 8 May 2018, after a trademark sunrise from 29 March and a descending-price Early Access Program from 1 to 8 May. There has been no change of operator since.

One fact about .app matters more than everything else on this page, and buyers routinely discover it only when their site fails to load. The entire .app top-level domain sits on the HTTP Strict Transport Security preload list, usually shortened to HSTS preload: a list of names that the major browsers ship hard-coded inside the browser binary, instructing them never to connect over plain HTTP. This is not a redirect. A browser given an http:// address on a .app hostname does not send the request at all; it rewrites the address to https:// internally, before a single packet leaves the machine.

The consequence is blunt. A valid TLS certificate is mandatory before a .app site will load for anyone. Without one a visitor gets a hard failure, not a warning they can click through. Google Registry obliges registrars to disclose this encrypted-by-default requirement clearly and conspicuously before purchase, separately from general terms of service.

Who can register .app

Anyone, anywhere. There is no requirement to publish an application, no developer credential, no company verification and no geographic nexus. Registration is real time and first-come, first-served, and because nothing is declared there is nothing to audit and no false-declaration risk.

The real constraints are syntactic and technical. Google Registry extensions accept labels of 3 to 63 characters, so one- and two-character .app names are not generally available, and the namespace is ASCII-only. The HTTPS requirement is a condition of use rather than an eligibility rule: the registry never checks whether you hold a certificate and cannot grant an exception, because enforcement happens in the browser.

What .app costs to own

At registry level .app is a standard-priced new gTLD for non-premium names. The gap between year one and year two is created by registrars rather than by Google: heavily discounted first-year offers that revert to a materially higher standard renewal are the norm. The renewal is the number that governs what a name costs you.

Premium tiers exist and behave in a way that catches people out. Google Registry reserves short, generic and high-demand names at elevated pricing, and those names are generally premium at renewal as well as at registration. The elevated price recurs annually and follows the name through a transfer.

No .app registry increase surfaced in the January 2026 round of adjustments, though absence from one registrar's change list is not proof, and Google Registry publishes a per-TLD pricing policy worth checking. Restoring a lapsed name from redemption costs substantially more than renewing. Budget one line item most extensions do not need: TLS. In practice it is free, but the domain is unusable without it.

Registration terms, renewals, and transfers

.app registers for a minimum of one year and a maximum of ten, in whole-year increments. Auto-renewal typically triggers thirty days before expiry, and registrars document a forty-day post-expiry grace period at the ordinary renewal rate, followed by a thirty-day redemption window in which only the original registrant can restore the name, at a fee well above a renewal.

Transfers follow standard ICANN gTLD policy with no registry-specific mechanism: an authorization code, commonly called an EPP or auth code, from the losing registrar, and no transfer-prohibited status on the name. Sixty-day locks apply after initial registration, after a prior transfer and after a change of registrant, and a successful transfer adds one year.

Sequence migrations carefully: moving the registration does not move the certificate. On an ordinary extension a brief mismatch during cutover produces a warning; on .app it produces an unreachable site.

WHOIS, RDAP, and privacy

Since 28 January 2025, RDAP, the Registration Data Access Protocol, has been the definitive source of registration data for gTLDs, replacing the sunsetted port-43 WHOIS services. What is published is governed by ICANN's Registration Data Policy: most registrant contact fields are redacted in the public tier, leaving status, dates, name servers and sponsoring registrar visible.

Privacy and proxy services are permitted and are offered by registrars in the usual way, many bundling them at no extra cost. One timing restriction is rarely anticipated: privacy cannot be enabled for ninety days after a domain has been approved through the trademark-claims process.

DNSSEC is supported and registrant-manageable through DS records. Internationalized domain names are not supported, a hard stop for any brand that needs non-Latin script.

Who .app suits, and who should avoid it

.app suits software and SaaS companies, mobile app developers, dev-tool vendors, product landing pages, and startups whose brand simply is the app. It is unusually good for exact-match naming where the .com is gone, because the extension completes the phrase rather than decorating it, and for a security-conscious product the HTTPS mandate is a feature rather than a chore.

Avoid it if you need plain HTTP anywhere in the stack: legacy clients, embedded and IoT endpoints, internal tooling that cannot terminate TLS, and certain redirect arrangements all rule it out. Avoid it if the word app is semantically wrong for the business, since the extension makes a specific claim. Avoid it if you need internationalized characters, and avoid it if your stack cannot automate certificate renewal, because a lapsed certificate on .app does not degrade the site, it removes it. Buyers selling into conservative mainstream or financial audiences also pay a small trust cost a developer audience would never notice.

Common mistakes with .app

Three of the four recurring .app mistakes trace back to the same root cause.

• Pointing the name at a plain-HTTP host and concluding the domain is broken. This is comfortably the most common .app support ticket. The DNS is fine; the browser is declining to speak HTTP to a preloaded name. The fix is a certificate, not a DNS change.
• Setting up forwarding through a service that only serves HTTP on the source. A redirect from an http:// .app address never executes, because the browser never issues the request that would receive it. The forwarding service has to terminate TLS on the .app hostname itself, and many cheap products cannot.
• Letting the certificate lapse. Elsewhere an expired certificate produces a warning visitors can click past. Here it produces a hard, unbypassable failure across the whole site and every subdomain, since subdomains inherit the preload entry.
• Buying a premium .app as though the premium were a one-time cost. It recurs at renewal every year, and the obligation travels with the name when it changes hands.

A record auction, and the first namespace that could not be unencrypted

.app was one of the most fiercely contested strings of the 2012 round. ICANNWiki lists twelve applicants, including Google, Amazon, Donuts, Radix, Afilias, Famous Four Media, Top Level Domain Holdings and MacPaw's Dot App Inc. The set went to an ICANN auction of last resort on 25 February 2015, which Google won. The winning bid is widely reported at approximately $25 million, ICANNWiki and contemporaneous trade coverage giving $25,001,000. At the time it was the highest price ever paid for a new gTLD at an ICANN auction, a record later exceeded by .web. The format mattered as much as the number: because this was an auction of last resort rather than a private auction, the proceeds went to ICANN rather than being divided among the losing bidders. Amazon walked away with nothing.

What Google Registry's ownership means in practice is more interesting than the price. A registry owned by a large engineering company is not under the same pressure to maximise per-name volume as an independent portfolio registry, and it can make product decisions that cost it registrations. Putting the entire zone on the preload list is exactly that: it permanently excludes every buyer who needs plain HTTP, in exchange for a property no legacy extension can retrofit. .app was the first TLD to reach general availability with HTTPS mandatory across the whole zone, and it created the secure-by-default namespace as a product category.

Be exact about the mechanism, because it is widely misunderstood. HSTS preloading is a browser-side list, not a registry enforcement mechanism. Browser vendors compile it and ship it inside the binary, which is why it takes effect before any network activity, even on a first visit to a name the browser has never seen. Charleston Road Registry does not inspect certificates and cannot grant an exception. Because the entry covers the whole top-level domain, every .app name is on the list from the instant it is registered, and subdomains inherit it. There is no opt-out. A registrant cannot have a name removed from preload, cannot serve a plain-HTTP version alongside the secure one, and cannot ship a self-signed certificate without breaking every default-configured browser. The same design covers Google Registry's other preloaded extensions, among them .page, .new, .day and .zip.