.dev vs .app: Two Google TLDs, Two Audiences
Both extensions are run by Google's registry and both force HTTPS in the browser, so the technical choice is mostly about what the name says to a visitor. This page covers the shared plumbing, the real differences, and what to check before you launch.
What they share
IANA lists Charleston Road Registry Inc., with Google as the administrative and technical contact, as manager of both .dev and .app. Both are open to anyone, with no eligibility rules, and both are on the HSTS preload list, so browsers connect to them only over HTTPS. Google's registry pages describe both as secure by default.
That shared foundation means the setup work is identical: you need a valid TLS certificate before a visitor sees anything, and an http:// address will not load.
Timeline
The dates are easy to mix up because the IANA delegation and the opening to the public are different events.
| .app | .dev | |
|---|---|---|
| Delegated in the root zone (IANA) | July 2015 | December 2014 |
| Opened to general registration | 8 May 2018, timed to Google I/O | 28 February 2019 |
| Positioning on Google's registry page | Developers, startups and software creators; launching apps, tools and product pages | Developers; documentation, open source, portfolios and engineering blogs |
So .dev was delegated earlier but launched later. Neither is new anymore, so both have track records for stability and no longer carry launch-era pricing noise.
Audience: who the name speaks to
The extensions are technically interchangeable but they frame a site differently.
- .dev suggests a person or team building software. It fits personal sites, API documentation, SDK homepages, libraries and technical blogs. A reader expects to find code, docs or a developer-centric product.
- .app suggests a product people use. It fits consumer and business applications, a landing page for a mobile app, or a SaaS front door. A reader expects something to download or sign in to.
A useful test: would you say the name aloud as "dot dev" in a conference talk, or put it on a billboard for a mobile app? Neither extension is meaningless to non-technical users, but .app maps more clearly to the word consumers already know.
Use cases that favour each
Lean toward .dev when
- The site is documentation, a developer portal, a changelog or a code-heavy blog
- You are an individual or open-source maintainer branding your work
- The audience is other engineers
Lean toward .app when
- The primary page promotes an app or a product people install or log in to
- You want a name that non-developers read instantly
- You plan separate marketing and docs sites
Plenty of teams use both: the marketing site on a .com or .app, the docs on a .dev subdomain or a separate .dev domain. Nothing prevents it, and it lets each name do what it signals best. For how these compare with other startup choices, see .com vs .io vs .ai vs .app.
HTTPS, mixed content and what actually breaks
Preloading applies at the TLD level, so no one has to opt in. That brings a few practical consequences.
Certificates first
Provision the certificate before you point the domain at a host. A site without one is not "insecure but visible"; the browser refuses to proceed. Most managed hosts issue certificates automatically once DNS resolves to them, which can leave a short gap right after you add a domain.
Mixed content
Browsers block or upgrade insecure subresources on HTTPS pages regardless of TLD, but sites moving from older http:// setups often hit this on first launch. Look for hard-coded http:// links to images, scripts or APIs in templates, CMS content and third-party embeds. Internal links to other subdomains on your own domain also need HTTPS, because the preload rule applies to subdomains as well, and a test server on a plain-HTTP subdomain will not open in a browser.
Local development
If you use a real .dev or .app hostname for local testing, you need a trusted local certificate. Many developers avoid this by using localhost or a reserved name for local work and the real domain only for staging and production.
HSTS preload affects browsers, not other protocols. Command-line tools, webhooks, API clients and mail servers do not use the browser's preload list, though servers may separately choose to require TLS.
Email and DNS
Email on .dev and .app works like email on any other extension. MX records, SPF, DKIM and DMARC are set in DNS as usual, and the HSTS preload list does not change mail delivery. Two practical points:
- Webmail, mail-server admin panels and autoconfiguration pages served from your own domain over a browser need HTTPS because they are web pages.
- Recipients and filters sometimes treat unfamiliar extensions with extra scrutiny, so authentication records matter more than the TLD itself. Set them up correctly and test deliverability early.
The guide to DNS and nameserver providers covers where those records live and how to switch providers safely.
Naming patterns that work on each
Because neither extension carries a word you want to repeat, the label before the dot should do the work. Compound names that read as a phrase work well: a hypothetical example.dev reads as "example, for developers", and example.app reads as "the example app". Avoid names where the extension creates an unintended word or the label already contains "dev" or "app", which reads as redundant and is awkward to say aloud. Single dictionary words are heavily contested in both and may be priced as premium by the registry, so expect to be flexible.
It also helps to decide how you will write the name in prose. Teams who put a domain in documentation or social profiles tend to write it in full each time; check that auto-linking and email clients handle it as a clickable link, since newer extensions are occasionally missed by old link detection.
Checklist before you register
- Check that the name is clear when read aloud with the extension attached.
- Check the .com and the other Google extension. If you own one, the other is a cheap protective registration.
- Confirm your host provisions TLS automatically for the domain.
- Look at renewal pricing, not just the first-year price, at your registrar.
- Set up SPF, DKIM and DMARC before sending any mail.
The detailed profiles are in the .dev guide and the .app guide.
Frequently asked questions
Are .dev and .app run by the same company?
Yes. IANA lists Charleston Road Registry Inc., part of Google, as the manager of both extensions, and both are open to anyone without eligibility requirements.
Do both extensions require HTTPS?
Yes. Both are on the browser HSTS preload list, so browsers will not connect over plain HTTP. You need a valid TLS certificate before the site loads.
When did .dev and .app launch?
.app opened to general registration on 8 May 2018 and .dev on 28 February 2019, according to Google's registry. IANA records the root delegations earlier, in 2015 for .app and 2014 for .dev.
Does HSTS preload break email on a .dev or .app domain?
No. Mail delivery is governed by DNS records and mail servers, not by the browser preload list. Only web pages on your domain, such as webmail, must be served over HTTPS.
Which is better for a SaaS product?
Either works. .app reads more naturally to non-technical buyers, while .dev suits developer-facing products, docs and APIs. Many teams use .app for the product and .dev for documentation.