BUY WEBSITES
BUY DOMAINS
LOGIN
SIGNUP
.dev and .app domains: dev domain registration and the HTTPS-only rule explained
A sourced guide to dev domain registration on Google’s .dev and .app extensions: who runs the registry, how the HSTS preload list forces HTTPS, what each costs, and how the .dev-versus-.app choice is read.
The .dev and .app extensions are Google Registry’s developer domains, and dev domain registration is the first top-level domain signup where HTTPS is not a recommendation but a hard rule baked into the browser before a site is ever built.
The registrar blogs ranking for this query sell the developer credibility and the free padlock without explaining the mechanism that forces it, what it means for SEO, or what either extension costs.
This guide reads .dev and .app through sourced, dated facts instead of adjectives. It answers five questions in order:
- What .dev and .app actually are, who runs the registry, and why each one launched.
- How the HSTS preload list forces HTTPS on every .dev and .app site, with no opt-out.
- Whether the HTTPS-only design helps or hurts SEO, read as a generic-treatment fact.
- What .dev and .app cost to register and renew, and how the two extensions differ.
- When each extension fits, when it does not, and the aged and resale lens the guides skip.
The SEO answer is settled and the security design is the genuine differentiator. The question that decides the outcome is which name, carrying which history, the extension sits on, and that is the question a screened catalogue is built to answer.
This guide is general SEO and domain-market education about the .dev and .app extensions and the aged-domain market. It is not financial, investment, or legal advice, and it does not value or endorse any specific domain or extension.
Every figure cited is a sourced, dated data point from a named third party such as IANA, ICANN, Google Registry, the HSTS preload list maintainers, or registrar pricing, not a prediction or a per-domain valuation.
What .dev and .app domains are and who runs them
The .dev and .app extensions are generic top-level domains operated by Google Registry, launched in 2019 and 2018 respectively as secure-by-design developer domains where HTTPS is mandatory. The two extensions share one registry and one security model.
Both strings come from ICANN’s New gTLD Program, the 2012 expansion that opened the root to hundreds of new endings. Google’s registry arm, Charleston Road Registry Inc., applied for and now operates each one.
The .app extension carries the more famous origin. Google won it at the ICANN Auction of Last Resort on 25 February 2015 for US$25 million, the record price for a new gTLD at the time.
The positioning differs by a single word. The .app extension reads as “this is an application”, and the .dev extension reads as “this is built by developers”, and Google marketed both as homes for developer tools and technical products.
One registry runs both extensions, and the brand around it has shifted.
The operator chain matters because it tells a buyer who controls the policy. Charleston Road Registry, Google’s registry arm, has held both strings since their delegation and still sets the rules today.
The consumer-facing brand changed without changing the registry. Squarespace acquired the Google Domains retail business in 2023, so registrations moved to other registrars, while Google Registry kept operating the .dev and .app extensions themselves.
The classification that places .dev and .app among the generic extensions, against the country-code and sponsored types, is set out in Domain extensions list: Every TLD type and what each one signals.
How the HSTS preload list forces HTTPS on every .dev and .app
The .dev and .app extensions are HTTPS-only because Google entered both on the HSTS preload list at the TLD level before launch, so every modern browser refuses to load any .dev or .app site over an unencrypted connection. The rule lives in the browser, not on the server.
HSTS stands for HTTP Strict Transport Security. The preload list is a roster of domains, maintained by the Chrome project and built into Chrome, Firefox, Safari, and Edge, that the browser will only ever reach over HTTPS.
Google added .app, .day, .dev, .page, and .new to that list before they launched, per the Porkbun knowledge base. Because the entry sits at the extension level, it covers every name under it automatically and cannot be removed.
The practical effect is absolute. A .dev or .app site without a valid SSL/TLS certificate is unreachable, and the browser returns an “HTTP is disabled for this domain” message instead of the page.
Why developers adopted the .dev and .app domains
Developers adopted .dev and .app because the extensions read as native tech signals, short names remain available, and the forced-HTTPS design removes the certificate decision from the launch checklist. The appeal is part branding and part engineering convenience.
The category signal is the first draw. To a developer audience, a .dev address reads as a technical product before the page loads, the same in-group meaning a general extension lacks.
Google reinforced that read by building both extensions for the audience and using them itself, pointing developer tools and documentation at .dev and .app addresses. The endings became shorthand on Hacker News, GitHub, and Product Hunt.
- .dev signals “built by developers” to the exact audience that reads it as native.
- .app signals “this is an application”, the most literal ending for a web or mobile product.
- Short, brandable names the .com space exhausted years ago remain registrable.
- Google’s own use of both extensions lent each one early credibility in tech circles.
- HTTPS is forced by design, so the certificate is a precondition, not a forgotten step.
- No mixed-content drift, because an insecure version of the site cannot exist.
- The secure-by-default posture matches how modern teams already ship.
- One registry and one clear policy across both endings reduces guesswork.
The forced-HTTPS design is a convenience for builders and a constraint for shortcuts.
The security model cuts two ways, and reading it as a pure upside misses half the picture. For a team that intended to use HTTPS anyway, the preload rule removes a decision and guarantees the outcome.
For a quick throwaway page or a local test setup, the same rule is friction, because the site will not load until a valid certificate is in place. That trade is the reason a share of developers caution against .dev for casual test environments.
The honest read is that .dev and .app reward operators who treat security as a baseline and penalise those who wanted to skip it. The extension matches where the audience and the engineering posture already expect encryption.
Are .dev and .app domains good for SEO
The .dev and .app extensions are good for SEO in the only sense that matters: Google treats new gTLDs including .dev and .app as generic, so they carry the same ranking ceiling as .com, with no inherent advantage and no penalty. The extension does not rank the site.
The durable, dated fact is that the New gTLD Program extensions read as generic gTLDs to the ranking systems. A .dev or .app name competes on content, links, and user signals, exactly as any generic extension does.
The forced-HTTPS design adds one small, real wrinkle. HTTPS is a lightweight positive ranking signal, so a .dev or .app site can never sit on the wrong side of the HTTP-versus-HTTPS hygiene line.
That advantage is marginal and easy to overstate. A .com on HTTPS already captures the same signal, so the forced design closes a gap instead of opening a lead. The extension itself is not a ranking factor.
| Factor | .dev / .app | .com | SEO read |
|---|---|---|---|
| Direct ranking ceiling | Same as any gTLD | Same as any gTLD | No ranking gap; the extension is not a ranking factor |
| Google treatment | Treated as generic gTLDs | Generic gTLD | Both read as global; neither carries a geo-targeting constraint |
| HTTPS posture | Forced by HSTS preload | Optional, owner-configured | A marginal positive hygiene signal a .com on HTTPS already matches |
| Trust and recall (general audience) | Lower; less familiar outside tech | Highest; the default users assume | .com wins the remembered visit; the gap narrows inside a tech audience |
| Registration price | ~$11–$20 / year | ~$10–$15 / year | A small holding-cost difference, not a ranking one |
The HTTPS edge is real and small, and the trust gap is a click effect.
The distinction that keeps the .dev and .app SEO answer honest is the one the registrar blogs blur. The forced-HTTPS design is a genuine convenience and a marginal hygiene signal, not a ranking lever that lifts a name above a comparable .com.
The familiarity gap is the larger real-world factor, and it lives outside the algorithm. A general-audience user who defaults to .com when uncertain can skip an unfamiliar .app, which moves click-through and type-in traffic the ranking position never captures.
Inside a developer or startup audience that gap narrows toward zero, because the audience reads these endings as native. The practical reading is that .dev and .app are SEO-safe choices whose real costs are recognition and a small holding premium, not ranking.
The full evidence on why no gTLD outranks another, and how trust and recall reach SEO through the side door, is set out in Does your domain extension affect SEO? The data, the myths, and the aged-domain nuance.
The framework for choosing an extension as a trust-and-risk decision is in Best TLD for SEO: how to choose the right domain extension.
Dev domain registration cost: what a .dev or .app domain costs to register and renew
A .dev domain costs near $11 a year and a .app domain near $13 to $20 a year at mainstream registrars, with the price flat between the first year and renewal, unlike the deep-discount model a .io or a .xyz uses. The renewal is close to the registration, which is the buyer-friendly part.
Namecheap recorded .dev at $10.98 and .app at $12.98 in 2026, and .app commonly lists from $14 to $20 a year across registrars. The standard rate is set by Google Registry and passed through by registered partners.
The pricing structure is steadier than the new-gTLD norm. Where a .xyz sells a first year under $2 and renews far higher, .dev and .app sit closer to a single flat rate, so the registration price is a fair guide to the holding cost.
| Price point | Figure | What it tells a buyer |
|---|---|---|
| .dev registration | ~$10.98 / year | Recorded at Namecheap in 2026; the .dev base rate is steady year over year |
| .app registration | ~$12.98–$20 / year | Namecheap near $12.98; .app commonly $14 to $20 across registrars in 2026 |
| Renewal posture | Flat, near registration | No deep first-year discount to unwind; the renewal tracks the registration closely |
| At-cost registrars | Registry pass-through | Cloudflare sells domains at registry cost with no markup, the floor for either extension |
| Renewal vs a .com | Modest premium | A small recurring step above a $10 to $15 .com, not the four-to-five-times gap a .io carries |
The holding cost is a budget line, not an SEO cost.
The disciplined way to read .dev and .app pricing is to separate the cost of holding from the value of the name. The renewal is steady and the premium over a .com is small, so the budgeting question is light.
The cost a buyer adds is the certificate, and on these extensions that is unavoidable by design. A valid SSL/TLS certificate is free through providers such as Let’s Encrypt, so the security requirement is an operational step, not a recurring fee.
The practical reading is that .dev and .app are inexpensive to hold and carry one non-negotiable operational requirement, encryption, that a serious project would meet regardless. The cost and the value of a name are separate reads, and the price is the easy one.
The .dev versus .app difference and which one fits
The .dev and .app extensions share a registry, a generic SEO treatment, and forced HTTPS, and they differ in positioning: .dev reads as a developer’s home and .app reads as an application’s address. The choice turns on what the name announces, not on ranking.
Both endings carry the same security model and the same neutral ranking treatment, so the technical decision is a wash. The signal each one sends to a reader is where they part.
The .dev extension fits a developer portfolio, an API or documentation site, a tech blog, or an internal tooling brand, because it reads as built by and for engineers. The audience is the developer community itself.
The .app extension fits a shipping product, especially a mobile or web application, because it tells a user what to expect before the click. It points outward at the people who use the software, not only the people who write it.
- Developer portfolios and personal engineering brands.
- API platforms, SDKs, and software documentation.
- Tech blogs and open-source project homes.
- Audiences on Hacker News, GitHub, and developer communities.
- Mobile and web applications shipping to end users.
- SaaS products that want a literal, user-facing address.
- Product brands that read as “this is the app” at a glance.
- Consumer-facing software where clarity beats insider signal.
The technical decision is identical, so the signal decides it.
The reading that helps a buyer is that the engineering and SEO questions are already answered the same way for both. Each ending is a generic gTLD, each is HTTPS-only, each shares the registry and the price band.
That leaves the audience read as the deciding variable. A name aimed at the people who build chooses .dev, and a name aimed at the people who use chooses .app, and the wrong choice sends a slightly off signal without changing a rank.
The deeper comparison across the wider extension landscape, including the tech-signal ccTLD case, is in .io domain: Is it good for SEO, what it costs, and what it is worth.
The governance layer behind every extension is in What is a TLD? The top-level domain explained, from the dot to the governance behind it.
When a .dev or .app domain fits and when it does not
A .dev or .app domain fits a tech-audience product that treats HTTPS as a baseline and wants a short, on-category name, and it does not fit a trust-sensitive general-audience brand, a no-certificate setup, or a buyer who skips the history screen on an acquired name. The decision is a fit-and-readiness read, not a ranking one.
Because both extensions share the ranking ceiling of every gTLD, the choice turns on the audience, the engineering readiness, and, for an acquired name, the history behind it. The matrix below traces each case.
The fit read sits below the choice of which name to build on.
The hierarchy holds on .dev and .app as on every extension. A strong, clean, relevant name on .app outperforms a weak name on a more familiar extension, because the name and its history are the levers the ranking systems read.
The extension contributes a neutral SEO treatment, a forced-HTTPS baseline, a tech-audience signal, and a low holding cost on top of that name. It cannot substitute for a weak name underneath, and the secure design does not screen the history.
The disciplined decision spends its attention on the name and, for an acquired domain, its abuse and link history first, and treats the .dev-versus-.app-versus-alternative question as the final fit check.
5 frequently asked questions about .dev and .app domains
The 5 questions buyers raise about the .dev and .app domains concern whether they are good for SEO, why they force HTTPS, what they cost, how they differ, and whether either is safe for a serious site.
The answers below are general SEO and domain-market education about the .dev and .app extensions, not financial, investment, or legal advice, and not a valuation of any specific domain.
Q1Is a .dev domain good for SEO?
A .dev domain is good for SEO in the sense that it is rank-neutral. Google treats new gTLDs including .dev and .app as generic, so a .dev shares the same direct ranking ceiling as a .com and carries no inherent advantage or penalty.
The forced-HTTPS design adds a marginal positive hygiene signal, since HTTPS is a lightweight ranking factor. A .com already on HTTPS captures the same signal, so the forced design closes a gap instead of opening a lead.
The ranking is decided by content, links, and user signals, not by the extension. The real-world cost is recognition with a general audience, which is a click effect outside the algorithm. This is general SEO education, not a verdict on any specific domain.
Q2Why do .dev and .app domains require HTTPS?
The .dev and .app extensions require HTTPS because Google entered both on the HSTS preload list at the TLD level before launch. The preload list is built into Chrome, Firefox, Safari, and Edge, so the browser refuses to load any .dev or .app site over an unencrypted connection.
The inclusion sits at the extension level, so it covers every name automatically and cannot be removed. Any http request is upgraded to https inside the browser before it connects.
A .dev or .app site without a valid SSL/TLS certificate is unreachable, and the browser shows “HTTP is disabled for this domain”. .app was the first top-level domain secured with built-in HTTPS. This is general technical education, not advice on any specific name.
Q3How much does a .dev or .app domain cost per year?
A .dev domain was recorded at $10.98 a year and a .app domain at $12.98 a year at Namecheap in 2026, with .app commonly listing from $14 to $20 a year across registrars. The standard rate is set by Google Registry and passed through by partners.
The pricing is steadier than the new-gTLD norm, with no deep first-year discount to unwind, so the registration price tracks the renewal closely. Cloudflare sells domains at registry cost with no markup.
The one unavoidable operational requirement is a valid SSL/TLS certificate, which is free through providers such as Let’s Encrypt. This is general pricing education, not an endorsement of any registrar.
Q4What is the difference between .dev and .app?
The .dev and .app extensions share one registry, Google Registry, the same generic SEO treatment, and the same forced-HTTPS security model. The difference is positioning. The .dev extension reads as “built by developers” and the .app extension reads as “this is an application”.
The .dev extension fits developer portfolios, API platforms, documentation, and tech blogs, because it points inward at the people who build. The .app extension fits mobile and web applications shipping to end users, because it points outward at the people who use the software.
The engineering and SEO decisions are identical for both, so the audience read decides the choice. This is general education, not advice on any specific name.
Q5Is a .dev or .app domain safe for a serious website?
A .dev or .app domain is safe for a serious website. The forced-HTTPS design guarantees encryption, the extensions are run by Google Registry, and Google treats them as generic gTLDs with no ranking penalty.
The real considerations sit outside the algorithm. A general-audience brand pays a small recognition cost on an unfamiliar ending, and every site needs a valid certificate to load at all.
For an acquired .dev or .app, safety also depends on screening the inherited backlink profile, topical history, and any spam, malware, or blacklist record, because the secure extension does nothing to clean a name’s past.
A clean, screened name is safe; an unscreened one carries hidden risk. This is general market education, not legal or investment advice.
How a screened catalogue weighs a .dev or .app domain
Every layer above resolves to one operational point. On a .dev or .app the extension is rank-neutral and secure-by-design, so the name, its history, and its abuse record are the asset a screened catalogue reads. The generic SEO treatment, the forced HTTPS, the developer signal, and the flat price all point the same way.
SEO Domains weighs a .dev or .app exactly that way at intake. The curated marketplace screens each aged domain, on these extensions as on any other, in a fixed order:
- Its inherited backlink profile, read for relevance and cleanness.
- Its topical history, read against the buyer’s intended use.
- Its abuse, spam, malware, and blacklist exposure, surfaced before acquisition.
- The extension last, read as a security-and-signal modifier on top of that screen.
Domain Authority, Domain Rating, Trust Flow, and Citation Flow are reported alongside the inheritance read, so a buyer sources a .dev or .app selected on the history that decides the SEO, with the forced HTTPS recognised as a baseline, not a substitute for diligence.
| .dev / .app trap in an unscreened pool | How a raw listing leaves it | What the SEO Domains catalogue screens for instead |
|---|---|---|
| Forced HTTPS sold as the whole value | A name is pitched on its padlock with no read of its history or abuse record | The screen reads the inherited link profile and topical history first, and the extension last as a security-and-signal modifier |
| Inherited blacklist baggage | An acquired .dev or .app arrives with a hidden spam, malware, or blacklist record the secure model cannot offset | The screen surfaces the abuse, spam, and blacklist exposure before acquisition, regardless of how clean the extension looks |
| Thin name with no real equity | A metric-rich shell reads as value despite hollow or engineered links | The screen reads link relevance and cleanness so inherited equity is genuine, not padded |
| Tech signal mistaken for ranking power | A buyer reads the developer ending as an SEO advantage it does not carry | The screen treats the extension as rank-neutral and reads the name and history that actually decide the outcome |
| Certificate readiness ignored | A buyer registers without a plan for the mandatory SSL/TLS certificate the extension requires | The screen notes the forced-HTTPS requirement as a known operational precondition of holding the name |
The catalogue reads inherited equity and abuse exposure before the extension.
The discipline SEO Domains applies is to invert the order the registrar blogs encode. A raw .dev or .app listing prices a name on its secure ending and leaves the history and the abuse record unread.
The catalogue reverses that. It reads the inherited backlink profile for relevance and cleanness, reads the topical history against the buyer’s intended use, reads the abuse, spam, malware, and blacklist exposure, and only then reads the .dev or .app as the security-and-signal modifier it is.
An aged .dev or .app with a clean, relevant, abuse-free profile combines an SEO-safe generic treatment, a forced-HTTPS baseline, and a screened-clean history, and the screen makes all of it legible.
ICANN-accredited transfer applies to every acquisition regardless of extension, and the underlying diligence runs on RDAP after the WHOIS sunset of 28 January 2025.
A screened catalogue raises confidence in the name, and it guarantees no ranking outcome.
The honest takeaway is two-sided. A padlock sold as value, an inherited blacklist record, a thin shell, a tech signal mistaken for ranking power, and an ignored certificate requirement are real ways a .dev or .app decision goes wrong.
They concentrate in unscreened pools where a name reaches a buyer priced on its extension with its abuse history unread.
A screened catalogue does not abolish the build work an aged-domain project carries. It does not write the content, earn the new links, or run the conversion the inherited equity rewards, it does not provide financial, investment, or legal advice, and it promises no ranking or sale outcome on any name.
What it does is read the inherited equity, the topical history, and the abuse exposure that decide the outcome, and place the .dev or .app extension where the facts place it, as a security-and-signal modifier on top of the asset.
A buyer who finishes this guide is equipped to stop reading the padlock as the value and start reading the name, because on a .dev or .app the ranking was never in the extension and the history repeatedly is.
