Will logging in fix it?

Probably not — this happens before login. The Save File dialog appears as soon as your browser receives the homepage response, which is before the login form even has a chance to render. Try the quick fixes first (hard reload with Cmd+Shift+R or Ctrl+Shift+R, different browser, different network). If you can get the homepage to render, the dashboard and the rest of the app work normally.

Browser downloads our homepage instead of loading it?

If you opened warmysender.com and your browser popped up a "Save File" dialog instead of showing the website, this guide explains what happened, walks through the quick fixes that resolve it for almost every user, and shows how to send us a diagnostic capture if the problem persists. Most of the time the fix is one hard reload away.

WarmySender is a 4-pillar outreach platform — Cold Emailing, Email Warmup, LinkedIn Outreach, and Multichannel sequences. This guide covers a rare browser-rendering issue that does not affect any of those pillars in the platform itself — your data, campaigns, mailboxes, LinkedIn accounts, and inbox are unaffected.

Why this happens

When your browser receives a webpage, our server attaches a small set of headers that say "this is HTML, render it inline." If those headers are stripped, altered, or missing on the way to your browser, the browser refuses to guess and offers the page as a download instead. There are three common reasons that can happen:

Your network provider's filtering or transparent proxy. Some ISPs, mobile carriers, and corporate networks intercept HTTPS traffic for inspection and re-emit the response without preserving the original headers. When the Content-Type header gets stripped, browsers with strict MIME-sniffing protections (every modern browser) will treat the response as a generic file and download it.
Mid-deploy or restart on our side. Extremely rare and self-resolves within seconds. If you happened to load the site during a restart window, the response can ship without the right headers. A hard reload after a few seconds always resolves this.
Browser extensions or corporate antivirus that aggressively scan HTTPS traffic. Some anti-virus products and content-filter extensions decrypt and re-encrypt every page you load. Aggressive ones strip response headers in the process, with the same end result as the network-filtering case.

Quick fixes you can try

In order, from fastest to most thorough. Most users stop at step 1 or 2.

Hard reload the page. On macOS press Cmd+Shift+R; on Windows or Linux press Ctrl+Shift+R. This bypasses your browser's cache and asks our server for a fresh copy of every byte. If the issue was a one-shot mid-deploy blip or a stale cache entry, this resolves it immediately.
Try a different browser. Open warmysender.com in Chrome, Firefox, Safari, or Edge. If the page loads in one browser but downloads in another, the issue is browser-side (extension, content filter, or aggressive AV) and isolating which browser is affected helps narrow down the cause.
Try a different network — VPN, mobile data, or hotspot. Switch off your Wi-Fi and use your phone's mobile data, or turn on a VPN. If the page renders correctly on a different network, the issue is your current network's filtering or transparent proxy mangling the response before it reaches your browser.
Temporarily disable browser extensions and corporate antivirus HTTPS scanning. If you have antivirus software with "web protection" or "HTTPS inspection" enabled, pause it briefly and reload the page. Same idea for browser extensions — try opening warmysender.com in an incognito / private window with extensions disabled.

If it keeps happening

If the page still downloads after those four steps, please send us a diagnostic capture so we can identify the network or filter that's altering our response. Three steps:

Open https://warmysender.com/__diag in the same browser where the issue occurs. The page returns a small JSON document showing the request and response headers our server sees and sends. It contains no account data and no secrets — just headers, your country, and your user-agent — and it is safe to share.
Take a screenshot of the JSON output (or copy-paste the full JSON into an email).
Email support@warmysender.com with the subject line "homepage downloads instead of loads". Please include: your country, your ISP or mobile carrier, your browser and version (e.g. Chrome 134 on macOS Sonoma), and roughly when the issue started.

With that information we can correlate against our server-side delivery logs, confirm whether the response left our infrastructure with all the right headers, and reach out directly to the network provider that's altering the response. Diagnostic captures from real users are the single most useful thing for diagnosing this — much more useful than a guess.

What we're doing about it

We've added Content-Disposition: inline and other defensive headers so browsers always render the homepage even if a network filter alters our response. The four redundant signals we now send on every HTML response are:

Content-Type: text/html; charset=utf-8 — the canonical "this is HTML" marker.
Content-Disposition: inline — the redundant "render, don't download" marker. Per RFC 6266, browsers default to inline rendering when this is present, even if Content-Type was stripped.
X-Content-Type-Options: nosniff — global Helmet header; explicit on every HTML send so a future config change doesn't silently regress this.
Cache-Control: no-store on 5xx fallback paths only — never want a busted error response cached at the edge.

We're also collecting diagnostic data via /__diag to identify network providers that mangle responses, so we can reach out to them directly. The endpoint is read-only, returns less than 1 KB, and is rate-limited so it can't be used as an information-disclosure surface.

If you're curious about how all of this fits together, our documentation hub has guides on every part of the platform.

Frequently asked questions

Is my account or data safe?

Yes — this is a display issue only. Your data, campaigns, mailboxes, LinkedIn accounts, warmup network, and inbox are completely unaffected. Nothing in our database changes based on whether your browser renders or downloads the homepage. The HTML file your browser saved is exactly the same HTML the rendered version would have shown — your account information was never at risk.

Probably not — this happens before login. The "Save File" dialog appears as soon as your browser receives the homepage response, which is before the login form even has a chance to render. Try the quick fixes above first (hard reload, different browser, different network) — those resolve the issue for almost every user. If you can get the homepage to render, the dashboard and the rest of the app work normally.

Is this only happening in Pakistan?

We see it most often from networks with aggressive filtering or transparent proxies, but it can happen on any network anywhere in the world. The defensive headers we ship now are global, not country-specific — they don't change based on where you're connecting from. If you're seeing this issue, it's worth running the quick-fixes checklist regardless of which country you're in.

Full documentation — Cold Emailing, Email Warmup, LinkedIn Outreach, and Multichannel guides
Support — How to get in touch with us about anything else
/__diag endpoint — Public diagnostic JSON for capturing request and response headers

Still stuck? Email support@warmysender.com with the subject line "homepage downloads instead of loads" and the diagnostic capture from /__diag — we'll dig in directly.