.app Domain
The Domain for Applications
Register your .app domain from just £20.99/yr. Free DNS management, email forwarding, and 10GB mailbox included with every domain.
What is a .app domain?
The .app domain is Google's secure namespace for mobile and web applications. Like .dev, every .app domain requires HTTPS, providing built-in security. It's the natural choice for app developers, SaaS products, and digital tools.
Who should register .app?
App developers, SaaS companies, and digital product teams.
Why choose .app?
- HTTPS required by default
- Managed by Google Registry
- Clear application identity
- Growing recognition among users
Who runs .app, and since when
Registry data from the .app delegation record held by IANA, which maintains the internet's root zone. Eligibility comes from the registry's own policy, and the prices are ours.
- Extension type
- Generic (gTLD)
- Registry operator
- Charleston Road Registry Inc.
- The organisation that runs the extension
- In the root zone since
- 2015
- Delegated 25 June 2015
- Who can register
- Open to anyone worldwide, but every .app site must be served over HTTPS
- Checked against the registry's own policy
- Our price
- £20.99 a year
- Ex VAT. Renews at the same price
Why every .app domain is forced onto HTTPS
Most extensions are a naming decision. .app is a naming decision with a configuration requirement bolted to it, and that requirement is the most useful thing to understand before you buy one. Google Registry put the whole extension on the HSTS preload list before it opened, so browsers refuse to make a plain HTTP request to any .app address, anywhere, ever.
The timeline is short. .app was delegated on 25 June 2015, ran a sunrise period for trademark holders from 29 March to 1 May 2018, an early access period from 1 to 8 May 2018 where anyone could pay an extra fee to register ahead of the queue, and general availability from 8 May 2018. Charleston Road Registry, Google's registry business, has been the manager throughout.
What HSTS preloading does to your site
Preloading works inside the browser, before the network is involved. Chrome, Firefox, Safari and Edge all ship with a list of names that must be reached over HTTPS, and .app sits on that list as an entire extension rather than one domain at a time. The browser rewrites http:// to https:// on its own and then connects. The port 80 redirect you would set up on any other domain never runs, because nothing ever arrives on port 80. If your certificate is missing, expired or does not cover the name being requested, the visitor gets a failed connection rather than a warning they can click past.
That has three consequences worth planning for. You need a working certificate before the domain does anything at all, including a holding page. Subdomains are covered as well, so staging and admin hostnames need one too. And you cannot opt out, because the listing belongs to the extension and not to your registration. On our hosting a free certificate is issued for the domain, so none of this costs you anything; on a server you look after yourself, sort the certificate before you point the DNS rather than after. Email is untouched by any of it, because HSTS governs web requests and says nothing about MX records or mail delivery.
Our steer: .app is a strong address for a product and a weak one for a brochure. The pattern that works is a .co.uk or .com carrying the company and the marketing, with a .app carrying the thing customers actually log into.
HTTPS is required to connect to all .app websites, helping protect against ad malware and tracking injection by ISPs, in addition to safeguarding against spying on open WiFi networks.
What that means if you are buying one
That is written as a benefit, and it is one. Read it as a precondition as well. On any other extension HTTPS is a task you can schedule; on .app it is the difference between a site that exists and a domain that does nothing. Order the certificate before you announce the address.
Is .app the right choice for you?
We would rather sell you the right extension once than the wrong one twice.
.app works well if
- The URL is the product. A web app, a dashboard or a customer portal reads correctly on .app in a way it never quite does on a company .com.
- You already run HTTPS on everything you ship, so the enforcement costs you precisely nothing and removes a class of mistake.
- Your company name has gone across .com and .co.uk, but the product name is free on .app.
- The address gets said out loud a lot. "App" is one syllable, everybody can spell it, and nobody asks you to repeat it.
Look elsewhere if
- You cannot promise a valid certificate on every host and subdomain you will use. On .app a broken certificate is not a warning screen, it is a site nobody can reach.
- What you are building is a local service website. .app tells the wrong story, and a .co.uk costs less and carries a UK search signal that .app does not.
- Something old has to connect to it: an embedded device, a legacy integration or a client that only speaks HTTP or an outdated TLS version. Those simply cannot reach a .app address.
- You expect people to reach you by typing the name from memory. Habit still puts .com on the end of anything that sounds like a product.
Building a website rather than a product? A .co.uk costs less and carries a UK signal that .app cannot. See .co.uk pricing.
.app vs .com: which should you register?
The real question is usually not .app against .com but .app against a subdomain of the .com you already own. app.yourcompany.com costs nothing extra, inherits your existing certificate setup and keeps everything on one name. That is a decent answer and plenty of good products use it.
Where a .app earns its money is when the product needs its own identity: a separate brand, a name shorter than the company name, or a thing you might one day sell or spin out. It also settles the HTTPS question permanently, because on .app there is no option to get it wrong. Where .com wins is cost, familiarity, and not tying your product address to a rule you cannot switch off.
If you go with .app, register the matching .com or .co.uk as well if it is free. People will type it, and you would rather that traffic reached you than somebody else.
| .app | .com | |
|---|---|---|
| Type | Generic, run by Google Registry | Generic |
| In the root zone since | 2015, on sale from May 2018 | 1985 |
| HTTPS | Required, enforced by the browser | Optional |
| Can you opt out | No, the whole extension is preloaded | Yes, HSTS is per domain |
| What visitors assume | Software you sign in to | A company website |
| Annual cost | A little above a .com | Lower |
.app domain questions, answered
What people ask us before registering a .app domain.
Can't find what you're looking for?
Ask us directlyYes, and before the domain does anything at all. Browsers will not send a plain HTTP request to a .app address because the extension is on the HSTS preload list, so there is no unencrypted version of your site for anyone to land on first. That applies to a holding page, a redirect and a staging subdomain equally. On our hosting a certificate is issued for the domain free of charge, so in practice this is one setting rather than a purchase.
Visitors get a connection failure, not a warning they can dismiss. On an ordinary domain a missing or expired certificate produces a scary interstitial that a determined visitor can click through, and http:// still resolves. Neither escape hatch exists on .app: the browser upgrades the request before it connects and then finds nothing valid at the other end. Treat certificate expiry monitoring as a requirement on this extension rather than as good housekeeping.
No. The entry on the list is the extension itself, not your individual registration, so there is nothing on your domain to remove and no form to submit. That is the deal you accept when you register one, and for most buyers it is the attraction rather than the cost. If you need the ability to serve anything over plain HTTP, even temporarily for a legacy client or a device that cannot do modern TLS, .app is the wrong extension for that project.
No. Nothing in the registry rules limits it to mobile, and web apps, SaaS dashboards, internal tools and desktop software all sit on .app perfectly happily. Where it does read oddly is on a site that is not software at all. A plumber or a solicitor on a .app is fighting the extension rather than using it, and the visitor has to reconcile an address promising a product with a page offering a service.
No. HSTS is a web mechanism, so it governs what browsers do with http:// and https:// URLs and has nothing to say about mail. Your MX records, mailbox and email forwarding on a .app domain behave exactly as they would on any other extension. Every domain we register includes free DNS management, email forwarding and one free 10GB mailbox, and .app is no exception to that.
Charleston Road Registry Inc., Google's registry business, is the manager recorded in the IANA root zone database and has been since .app was delegated on 25 June 2015. The registry is a separate thing from where you buy the domain: any accredited registrar can sell you a .app, including us, and the registry sets the rules rather than the retail price. The HSTS preloading is a registry-level decision, which is why no registrar can turn it off for you.
Included with Your .app Domain
DNS Management
Full DNS zone editor to manage A, CNAME, MX, TXT, and all record types.
Email Forwarding
Set up professional email addresses and forward to any inbox.
Auto-Renewal
Never lose your domain with automatic renewal protection.
Free 10GB Mailbox
One 10GB mailbox (POP3/IMAP) included with every domain, on any TLD.
Other Technology Domains Extensions
Register your .app domain today
Secure your .app domain from just £20.99/yr. Free DNS management, email forwarding, and 10GB mailbox included.
