.dev vs .com for a Developer Portfolio or Product

Choose .dev when the domain is for a developer portfolio, technical documentation, open-source project, API, developer tool, or product whose technical audience immediately understands the signal. Choose .com when the address represents a parent company, serves a broad nontechnical market, or must remain useful after the business moves beyond developer products.

The extension is only part of the name. A short northstar.dev can be clearer than northstardeveloperplatform.com. A clean northstar.com can be broader than either. Compare realistic names that are actually attainable and investigate the matching-domain conflict before registering.

.dev also has an operational rule that changes launch planning: browsers require HTTPS for every .dev website. The namespace is suitable for public development work, but it should not be used as an improvised private testing suffix.

1) Identify the audience before the extension

The word after the dot sets an expectation before anyone reads the page.

Google Registry describes .dev as a home for tools, platforms, languages, blogs, projects, and documentation. That is useful positioning, not a rule that only employed software developers may register one. General availability opened in February 2019.

When the primary visitor is a customer buying payroll, healthcare, logistics, or retail services, a developer signal may create the wrong first impression even if software powers the product.

2) Compare names you can actually obtain

If the exact .com is registered, do not compare it with an available .dev as though both cost the normal registration fee.

The real shortlist may be:

• northstar.dev;
• getnorthstar.com;
• northstarhq.com;
• a different brand label under .com;
• a relevant country-code domain; or
• acquisition of northstar.com if its owner is willing and the transfer is safe.

Score each complete address for spelling, speech, length, audience meaning, repetition, matching-name conflict, email, future scope, rights, and full-term cost.

Avoid labels such as northstardev.dev unless the repetition is an intentional brand. The extension already supplies the developer signal. Also test whether “dot dev” is heard correctly in calls and presentations; some listeners will otherwise type northstardev.com.

3) Investigate the matching .com

An available .dev does not erase an active matching .com.

If northstar.com sells a related developer product, launching northstar.dev can create mistaken visits, support requests, emails, package-name confusion, or an assumption that the products are affiliated. If the .com is an unrelated astronomy publication, practical confusion may be lower. Trademark and company-name checks still apply.

Before registration:

1. Open the exact .com, .dev, and relevant country-code domains.
2. Search the label without a suffix.
3. Check company registers, trademarks, GitHub organizations, package registries, app stores, and social accounts.
4. Classify each match as active and related, active and unrelated, parked, for sale, redirected, or unresolved.
5. Test whether the same developer or buyer could encounter both projects.

Use WHOIS research and ICANN Lookup for registration context. Privacy-redacted ownership and an empty website do not establish that the label is safe to adopt.

4) Plan for mandatory HTTPS

IANA classifies .dev as a generic top-level domain and lists Charleston Road Registry Inc., Google's registry company, as sponsor. Google Registry's policy requires registrars to disclose that .dev is encrypted by default and that HTTPS must be configured for browsers to load a website.

The namespace is HSTS-preloaded. Browsers request HTTPS even when someone types an http:// URL and will not fall back to an unencrypted page when the certificate fails.

Before launch, test:

• apex, www, documentation, API, status, and authentication hostnames;
• certificate issuance and automatic renewal;
• redirects from any previous domain;
• CDN, proxy, load balancer, and origin settings;
• mixed HTTP assets;
• webhooks, OAuth callbacks, and CORS allowlists; and
• third-party documentation or status services using custom hostnames.

HTTPS protects the browser connection. It does not verify the developer's identity, audit the code, prevent a compromised server, or endorse the product.

5) Do not use .dev as a private test suffix

Before .dev became a public top-level domain, some teams used names such as project.dev only on local networks. That is now unsafe and unreliable: .dev is real public DNS, and browsers enforce HTTPS for it.

The RFC Editor's RFC 2606 reserves .test for testing DNS-related code and .localhost for loopback use. Choose a development pattern that cannot collide with a public registrant:

• project.test with local DNS or a hosts-file entry;
• localhost with an explicit port;
• a subdomain you control, such as dev.example.com;
• a platform-provided preview hostname; or
• an internal zone managed by the organization with documented split-DNS behavior.

Production parity may require local HTTPS, secure cookies, service workers, WebAuthn, or OAuth callbacks. Configure those deliberately. Buying project.dev is not a shortcut to private local routing; it creates a public domain asset with renewal and security obligations.

6) Choose the right portfolio identity

For an individual developer, the decision is often between a name-based .dev, a .com, and a local country-code domain.

.dev can make the portfolio's purpose obvious in a résumé, GitHub profile, conference bio, or technical article. .com can remain useful if the person later moves into management, writing, investing, education, or a nontechnical business.

Test the complete address in:

• a spoken introduction;
• an email address;
• a résumé header at small size;
• a code comment or package README;
• a presentation slide; and
• a search for the person's full name.

Do not add “developer” mechanically to both the label and suffix. janedoe.dev is usually cleaner than janedoedeveloper.dev. If the exact name conflicts with another professional, add a meaningful qualifier or choose a different identity rather than relying on the extension to distinguish two people.

7) Separate company, product, docs, and API

A software business can use more than one domain layer without splitting its identity unnecessarily.

One coherent pattern is:

• company.com for corporate, legal, hiring, and sales pages;
• product.com or a product subdomain for the customer-facing product;
• developers.company.com for developer resources; and
• a short .dev address that redirects to documentation or hosts an independent developer tool.

Another is to make product.dev the canonical home when developers are both buyer and user. The choice should be explicit. Serving the same pages on .com and .dev without permanent redirects and canonical rules creates duplicate maintenance and unclear links.

Count the operational cost of every additional domain: renewal, DNS, certificates, monitoring, abuse response, redirect testing, and account recovery. Defensive registration can be sensible for a high-risk name, but it is not automatically valuable for every portfolio.

8) Configure email separately

The HTTPS rule applies to websites. Mail at hello@northstar.dev depends on separate DNS, provider, authentication, and sending reputation.

Configure:

• MX records;
• SPF for authorized senders;
• DKIM signing;
• DMARC policy and reporting;
• monitored security and abuse contacts;
• multi-factor authentication at the registrar and mail provider; and
• recovery access that survives an employee departure.

There is no credible universal rule that .dev mail reaches inboxes better or worse than .com. Filters evaluate many signals, including authentication, IP and domain reputation, message content, sending behavior, list quality, and recipient engagement.

For cold outreach, test with the actual provider and audience rather than repeating unsourced percentage claims. For product mail, keep password resets, receipts, and support replies on a consistent, recognizable domain.

9) Apply the SEO rule

Google's Search documentation states that a top-level domain does not determine a site's performance in Google Search. A .dev page can rank when it is the best relevant result. .dev receives no automatic boost for developer queries, and .com receives no automatic boost for age or familiarity.

The name can still influence people:

• a technical suffix can clarify the audience before a click;
• a concise address may earn more accurate links;
• a confusing one may produce misspellings or wrong-domain visits; and
• an active matching .com can compete for branded searches.

Those are audience and identity effects, not a documented algorithmic preference.

If an established site moves between extensions, map every URL, preserve content and internal links, use permanent redirects, update canonicals and sitemaps, retain the old domain, and monitor indexing. Do not migrate solely for an assumed ranking benefit.

10) Compare three-year ownership cost

Two current controls show .dev renewing modestly above .com.

Namecheap displayed these USD prices on August 16, 2026:

The three-year total is one registration plus two renewals at the displayed renewal rate, not Namecheap's separate multi-year checkout promotion. Under this example, .dev costs $4.70 more. Namecheap says a $0.20 ICANN fee may be added and premium names are excluded from the promotion.

OVHcloud's Canada pages displayed:

Here, .dev costs C$7.82 more across three years. OVH listed a 35-day grace period, 30-day redemption period, and C$198.09 restoration price for .dev.

Taxes, future changes, premium labels, privacy, and service add-ons can alter the total. Recheck the exact domain at checkout.

11) Use adoption evidence honestly

Google Registry reported more than 150,000 .dev registrations during the extension's first year, in a March 2020 retrospective. That is a historical launch milestone, not a current namespace total.

The same first-party post documented several distinct uses at the time: Atlassian used software.dev and cicd.dev for technical content, Cloudflare used workers.dev for its serverless platform, and Salesforce used lwc.dev for Lightning Web Components resources. Current use changes, so examples need rechecking rather than being copied indefinitely.

Checks on August 16, 2026 found:

• web.dev active as guidance for modern web experiences;
• slack.dev active as Slack's developer site;
• github.dev redirecting to vscode.dev/github/; and
• workers.dev redirecting to Cloudflare's current Workers product page.

An active primary site and a redirect are not the same adoption signal. These examples show that .dev can serve documentation, developer relations, browser tooling, platform infrastructure, and memorable redirects. They do not prove superior ranking or conversion.

12) Make the final decision

Choose .dev when:

• developers or technical teams are the primary audience;
• the domain represents a portfolio, tool, project, documentation set, API, or technical product;
• the complete name is clearer than attainable .com alternatives;
• matching names do not create material conflict;
• the team can operate HTTPS and certificates reliably;
• users reproduce “dot dev” correctly; and
• renewal and premium status fit the budget.

Choose .com when:

• the address represents the parent company or a broad product family;
• buyers are primarily nontechnical;
• the business may expand beyond developer products;
• a clean, conflict-free option is attainable;
• company-wide email and identity should stay on one domain; or
• testing shows repeated .com substitution for the .dev address.

Choose another route when neither complete name works. A country-code domain may fit one national market; .app may fit a user-facing application; .tech may fit a broader technology company; and a better brand label may be safer than a compromised exact word.