When I type example.com without any scheme into the browser bar and press Enter it is interpreted as HTTP://example.com, not HTTPS://example.com. Why? And where are the plans to fix this?

(To be clear, I'm talking only about typed/pasted addresses coming from a "lazy" user, not about software-defined actions such as following scheme-relative URLs, window.location = "url" etc. And obviously typing/pasting HTTP://example.com must still work.)

EDIT: As some answers point out sites already can mostly achieve this with redirects + HSTS. The central technical gain would be narrowing the first-connection problem (also addressed by HSTS preload but that can't scale to all sites). I can see how that's a weak justification for breaking things now; what I'm more interested in is whether it's an obvious endgame in 5 years? 10? 20?

I can see several problems on the way to defaulting to https interpretation:

  1. User experience with sites that only work over http. Defaulting to https would show an error but the user usually has no idea whether it should work, i.e. whether this site simply never worked over https or is this a downgrade attack.

    If the error page for this situation will contain an easy "did you mean http:...?" link(*), users will get used to clicking that on any site that doesn't work and we haven't gained much(?). And if it's not easy (e.g. user must edit https->http, users won't use such browser.

    EDIT: I should have clarified that the error indication must be different from explicitly going to an HTTPS address which failed — this scenario is not so much "fail" as "the safe interpretation didn't work". And for starters, even "soft failing" automatically to HTTP with a warning bar on top would be OK.

    But I think we still gain 3 things: going to unsecure site is a conscious action, we educate users that unsecure HTTP is not normal, and we put pressure on sites to implement https.

  2. Inconvenience of having to type http:// in some cases. IMO completely outweighed by convenience of not having to type https:// in more cases.

  3. "Compatibility" with the historical default. I'm not sure if it's enshrined in some standard, but IMO it's clear we'll have to change it some day, so that's not a showstopper.

  4. Politics/economics: the CA system has its issues and browsers might be reluctant to pressure site admins to pay them (if they don't otherwise see value in that). Let's ignore money for a moment and pretend Let's Encrypt free CA has arrived.

I can see why making the change right now can be controversial; what baffles me is why it's not widely discussed as the obvious long-term goal, with some staged plan a-la the SHA-2 certs deprection though maybe slower. What I see seems to assume http will remain default practically forever:

  • Chrome's move to hiding http:// in URL bar is a step back. The first step towards https default should have been showing http in red; at some later time eventually move to hiding https:// (only showing green padlock)...

  • HSTS moves in the right direction but with cautious per-site opt-in. It's both weaker and stronger — sites opt in to forcing https even for explicit http urls, with no user recourse for errors — but the RFC doesn't even mention the idea that https could be a global default, or that browser default scheme is to blame for bootsrap MITM problem.

  • I've seen DNSSEC mentioned as future vector for HSTS-like opt-in but again never saw proposals for opt-out...

Also, are there any browsers (or extensions) offering this as an option?

  • 8
    A good website would implement auto-redirects to the SSL version.
    – ps2goat
    Feb 16, 2015 at 22:40
  • 6
    @ps2goat: ...and a better website would (also) use HSTS. Even that still doesn't fully protect the first request, though. Feb 17, 2015 at 5:50
  • 13
    There is a fundamental flaw in the logic of preferring https to http: Where do you get the idea that https is better? The only thing https gains is security in data being transmitted from the client to the server. But that—in and of itself—is not always needed. Nor is your site magically secure because you are using https; for example a “secure” WordPress site using https is fairly vulnerable to attack if the version of WordPress has a security hole in it and an admin does not patch it. There is no real value to defaulting to https. If you think there is, you need to learn more. Feb 17, 2015 at 7:43
  • 6
    @ps2goat: auto-redirecting from http to https is not an ideal situation. An attacker could perform a man-in-the-middle attack and not redirect, and display a phishing site instead Feb 17, 2015 at 9:57
  • 7
    Vote to reopen. The other posts asks about adoption 'why is https not more popular?'. This question asks specifically 'why do browsers assume http rather than https?' an important question with an interesting security answer. Jun 30, 2015 at 15:57

8 Answers 8


Well, I can presume that a few reasons exist:

  1. HTTPS support is not automatically configured on websites. Therefore, why should browsers assume it is?
  2. Saying that a website is not accessible unless using a specific scheme would be over the heads of a significant number of users.
  3. Switching to HTTPS is not as simple as it seems in some cases. Take Stack Exchange for example.

These are timelines for some popular browsers to fix this:

Google Chrome

  1. Chrome 46

    Chrome will mark the “HTTPS with Minor Errors” state using the same neutral page icon as HTTP pages.

  2. Chrome 56

    mark HTTP pages that collect passwords or credit cards as non-secure

  3. Chrome 62

    Chrome will show the “Not secure” warning in two additional situations: when users enter data on an HTTP page, and on all HTTP pages visited in Incognito mode.

  4. Chrome 68

    the omnibox will display “Not secure” for all HTTP pages.

  5. Chrome 79

    Chrome will gradually move to blocking all mixed content by default. To minimize breakage, we will autoupgrade mixed resources to https://, so sites will continue to work if their subresources are already available over https://.

  6. Chrome 81

    Chrome will print a console message warning about all mixed content downloads.

  7. Chrome 84

    Chrome will warn on mixed content downloads of executables (e.g. .exe).

  8. Chrome 85

    Chrome will block mixed content executables

    Chrome will warn on mixed content archives (.zip) and disk images (.iso).

  9. Chrome 86

    Chrome will block mixed content executables, archives and disk images

    Chrome will warn on all other mixed content downloads except image, audio, video and text formats.

  10. Chrome 87

    Chrome will warn on mixed content downloads of images, audio, video, and text

    Chrome will block all other mixed content downloads

  11. Chrome 88

    Chrome will block all mixed content downloads.


  1. Firefox 51

    web pages which collect passwords but don’t use HTTPS will display a grey lock icon with a red strike-through in the address bar.

  2. Firefox 70

    we will start showing a crossed-out lock icon as permanent indicator for sites delivered via the insecure protocols HTTP and FTP.

  • 1
    Accepted as the only answer with (beggining of) a plan, and good example for (3). Steffen Ullrich and Bruno do a good job elaborating on (2). JamesRyan's comment made a great point that by the time this might be acceptable to users the protocols landscape will be different. Feb 19, 2015 at 17:57
  • 1
    There are plans to move toward HTTPS, first stage is making new features HTTPS-only. blog.mozilla.org/security/2015/04/30/… Although I don't know if any progress has been made since then. Apr 30, 2016 at 0:48
  • 1
    I would comment, continuing on Google's progressive fight against unencrypted http, that I expect in very few years browsers to automatically try https first, or even prefer to avoid plain http at all. As @Anonymous pointed in the second part of the answer, the process is in progress. How many is few years? Somebody from Mozilla, Google & Co should try to answer Jun 3, 2019 at 12:21
  • Firefox post from 2017 about showing red-crossed lock icon for http: blog.mozilla.org/security/2017/01/20/… Apr 27, 2020 at 22:28
  • @BeniCherniavsky-Paskin Thanks, I added it to the list.
    – Anonymous
    May 2, 2020 at 13:55

Browsers are applications for end-users. While the majority of sites is available by http (even if they just redirect to https) a significant part is not available by https. Thus your proposal would break web surfing for a very large part of the users. It would break in a way they don't understand. Automatically downgrading to http if https fails would not make sense because an attacker could then just simply cause havoc with connections to port 443 to enforce downgrades.

Once all but a few insignificant sites switched to https one could make the switch to a more secure default, but not yet. End-users would not understand what happened and probably just switch to an alternate browser or get some tips from somewhere on the internet to get back the old behavior.

Security decisions have to be done with and not against the users.

  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Rory Alsop
    Feb 19, 2015 at 13:52

There's a bigger issue at play here that would prevent your suggestion. The way many web servers are currently configured, you could actually end up on the wrong website if you defaulted to https. This is not true if you default to http.

For example, suppose you have 3 sites all on the same IP address:


On many servers, if you were to attempt to go to https://site.a.com, (instead of http), you will actually be looking at site C, but with a certificate error.

  • 3
    Yes, this is the biggest issue. It's usually caused by SNI not being configured for a particular site, so the server defaults to some other site. Also, not all sites on a shared host will have a certificate - how can the browser detect the case of "server is listening on 443 but there is no valid site for this host"? Simple answer: it can't. Not reliably. The same could be said for 80, but that's rarer for historical reasons mentioned in other answers.
    – Bob
    Feb 17, 2015 at 1:59
  • @Bob If the SNI-aware user agent connects with a server name that isn't among the sites on that IP with a certificate, then the server would just send the IP's default certificate. A subject name mismatch IMO would reliably indicate "no valid site for this host". Feb 19, 2015 at 0:52
  • 1
    @tepples That would open you up to a MitM. A MitM attacker could simply substitute a certificate with an incorrect SN or SAN and cause the browser to fall back to HTTP - very very bad.
    – Bob
    Feb 19, 2015 at 1:37
  • 1
    @Bob If HTTPS is specifically requested (UA has an HSTS preload for this hostname, UA has seen HSTS header on a previous visit, or the user entered https://), the UA would show the name mismatch page. The MITM opportunity would happen only on the first visit to a site not in the preload list when the user declines to specify a scheme, and it'd be no worse than today when HTTP is already assumed. Feb 19, 2015 at 1:44
  • @tepples Good point. The other issue remaining (relatively rare, but not unheard of) is a wildcard certificate where some subdomains are not actually accessible through HTTPS but still have a match on the SAN list. There's also an abundance of servers where the HTTPS connection works, but breaks the site (I ran the HTTPS Anywhere addon in the past, that will test for and connect to HTTPS whenever possible [as opposed to Everywhere that uses whitelists], and this became obvious quite quickly) - that goes back to webmasters assuming HTTP and never testing for HTTPS.
    – Bob
    Feb 19, 2015 at 2:05

I think there's a real danger of confusing a lot of users, which would make the situation even worse. Trying HTTPS everywhere isn't necessarily a bad idea, but there needs to be some sort of fallback plan for the user when HTTPS isn't available.

Many users aren't interested in warning signs, they just want their content. In many cases, protecting the traffic you get from eavesdropping or MITM attacks isn't strictly necessary, or at least the risk and consequences are much lower than a incorrect certificate on your bank.

Essentially, if the users get a warning sign when they try to get to their favourite HTTP-only site (e.g. a newspaper or some blog), you would have to teach them to ignore the warning, because it can still be OK in this case. Telling users to ignore warnings is generally a terrible idea, unless you really make sure they really understand ignoring that warning is OK, but ignoring others isn't.

Warnings are good, but numerous warnings for relatively low-risk problems are counter-effective, because the users are then likely to ignore all warnings (especially if they don't fully understand them).

Not many non-tech users try to understand the implications of the Firefox warning for a bad cert, for example:

This Connection is Untrusted

You have asked Firefox to connect securely to some.site.example, but we can't confirm that your connection is secure.

Normally, when you try to connect securely, sites will present trusted identification to prove that you are going to the right place. However, this site's identity can't be verified. What Should I Do?

If you usually connect to this site without problems, this error could mean that someone is trying to impersonate the site, and you shouldn't continue.

That's three paragraphs many users will not bother reading, at least not every time they encounter it, if it happens too often.

The main difference with a plain HTTP site is that the plain HTTP site doesn't claim to offer a secure connection. Assuming you can explain that in another three-paragraph message in a similar way. It would be quite common, even for tech-savvy users to be distracted and not read those explanations in full before choosing to proceed.

Many sites use http:// to https:// redirections, sometimes with 301 (permanent) status code or with HSTS. Pre-loaded HSTS is great but rare, HSTS on the first connection is reasonably good compromise.

At the end of the day, it will always be up to the user to expect the connection to be secure when appropriate. The browser can only do so much, but it's up to the user to check that HTTPS is in use when it makes sense to do so, and with the site they expect. It's not particularly different to real life: you don't need to check the passport of every one you ever talk to, but when things matter, you do.

There's a bootstrapping issue that cannot be conveyed within the realm of technology. If users goes to http://www.gmail.com/, they should be redirected to https://www.gmail.com/ or maybe https://mail.google.com/ or https://accounts.google.com/. It's out-of-band knowledge that tells them that they should expect HTTPS on Gmail, and that Gmail is run by Google. (The same out-of-band knowledge that tells them that HTTPS even exists...)

If they're not redirected, to an HTTPS site run by Google (Gmail or login), this is what should ring alarm bells with them. While an automated mechanism could work for a limited number of well-known sites, it's difficult to imagine a system that would work in general. Failing that, you still need the user to carry the responsibility to: (a) know when to expect HTTPS, (b) check that HTTPS is used and (c) check that they're indeed on the site they want. (Unfortunately, some browsers, especially on mobile devices, make that information a bit less visible.)

In my opinion, it's easier to teach a user those three points than to teach them to read the details of the warnings they may choose to ignore anyway.

Of course, you could imagine in the future a world where all the sites use HTTPS. I'm not yet entirely convinced this is necessary. Bad sites can get certificate too, so users will still have to carry the responsibility to check they're on the site they intended to visit anyway.

Trying to teach that plain HTTP is "not normal" is just pushing the problem to the next level. An all-HTTPS web can be a burden for the service providers, while not necessarily providing the benefits you'd expect.


The EFF has a plugin for Firefox (including Android), Chrome and Opera. It's called HTTPS Everywhere and it uses rules to make sure you end up on the right site. For example it'll rewrite example.com to https://secure.example.com/ if it knows that the https version only lives on secure.example.com. It even replaces urls inside links etc.


  • 1
    Indeed but it's kinda complimentary: it forces HTTPS on all requests but only to a set of whilelisted sites. The effect is akin to HSTS (with preload) except it wasn't sanctioned by the webmaster. I'm talking about affecting all urls but only when typed-in without a scheme. The "KB SSL Enforcer" plugin is a closer match: it tries HTTPS (with soft fail to HTTP) on first access, and if sucessful "pins" the site to always forced HTTPS. Feb 18, 2015 at 17:40
  • There is, in addition, a plugin that tries websites with HTTPS, sees if they work, and if so, adds them as a rule to your browser. code.google.com/p/https-finder - both together will mean that for any website which supports HTTPS, you will use HTTPS. Feb 19, 2015 at 3:39

Right now browsers use HTTP by default because it is what has been done for decades. It's not the browser's responsibility to ensure that the website is secure. It relies on the website to make the appropriate redirection and support HTTPS. Typing in google.com will redirect to the HTTPS version just fine. If a website supports HTTPS then it should put up the appropriate redirection. The browser has to be robust.

If the site supports both then it's like saying that your backdoor is left open, but your front door is locked.

  • 1
    I disagree with your last sentence. https doesn't protect the site, it protects the visitor. Maybe a better analogy would be, "Step into our dusty office. Here's a breathing mask that you can wear if you have allergies, asthma, or are just sensitive to dust. But if you step into room X, breathing masks are required for everyone, since we have toxic fumes in there."
    – TTT
    Feb 16, 2015 at 22:13
  • But that redirection doesn't protect against mitm attacks, because the attacker can simply replace the redirection with a legitimately-looking reply with no security.
    – kasperd
    Feb 17, 2015 at 9:21
  • 2
    I wouldn't call something that's vulnerable to SslStrip "just fine". Websites can't securely redirect from http to https. HSTS attempts to improve the situation a bit, but it only works reliably for sites that have been included in a list shipped with the browser (preloaded). Feb 17, 2015 at 14:00

Because computers used to be weak and encryption was cpu and internet bandwidth hungry and regarded as uneeded in the infancy of the internet.. You basically pack http in another layer and shove it over the pipe. This extra layer needs to do its own ceremonial tango in order to work, which means extra cpu, extra round trips, extra bandiwdth.. But things are changing, for example recent versions of chrome by default will try https nowadays. On the server side, however, you should setup a redirect as the only web content served on said domain which points the browser to the https flavor of the site.

  • 3
    "recent versions of chrome by default will try https nowadays" — do you have any more details on that? Perhaps you mean trying SPDY by default (which AFAIK only happens on an HTTPS url)? Feb 17, 2015 at 9:17
  • Trying to use https doesn't help against an active attacker if the browser silently falls back to insecure http if https did not work. Feb 18, 2015 at 14:51
  • 1
    I would also like to add that https costs more money. A good SSL certificate ( which empowers https) can go well over a couple of hundred $$ a year. This and the fact that you need to pay for more bandwidth, more CPU power and more ram to host HTTPS begs the question of why bother for a website such as stackexchange, or wikipedia for that matter. Most of the information is public anyways, and they don't make that much money off the website either. Who will pay for the added security?
    – user283885
    Feb 18, 2015 at 15:13
  • 1
    @user283885 For most websites a simple domain validated certificate is enough, and those typically cost around less than $10 per year. Even wildcard certificates aren't "well over a couple of hundred $$". The performance impact isn't that big either. For most websites the biggest cost by far is the time spent setting up SSL. Feb 23, 2015 at 12:29
  • 1
    @user283885 This is no longer true: letsencrypt.org
    – user7146
    Apr 20, 2017 at 8:18

Any website which requires security should redirect from http:// to https:// automatically. This would make the requirement for the browser to automatically view https:// redundant, and is a simpler solution than having to redirect from https to http for sites without certs.

This is something that shouldn't really be done anyway, which means the browser would have to put in security warnings, unnecessarily bothering the user like those annoying cookie warnings, etc.

  • 2
    Redirecting from http to https loses most of the security benefit of https. Feb 17, 2015 at 14:02
  • Really? How so? (BTW I mean redirect them as soon as they arrive on the site, so by the time they get to the credit card screen or whatever it is, they are well within https)
    – komodosp
    Feb 17, 2015 at 14:06
  • 6
    A MitM attacker can simply respond to that first unprotected request and omit the redirect. Unless the user notices that they weren't redirected (most won't), the attacker will be able to show them whatever they like. Feb 17, 2015 at 14:10
  • 1
    @CodesInChaos - I would disagree that "MOST of the security benefit of https" is to prevent MITM attacks. I think the main benefit of https is avoiding sniffed traffic, not the scenario you described. Besides, in your scenario the MITM can completely bypass the real site, and HTTPS would do nothing to prevent that. If you're claiming the user wouldn't notice they weren't switched over to https, they probably wouldn't notice the initial entrance to the site wasn't https either.
    – TTT
    Apr 23, 2015 at 18:27

Not the answer you're looking for? Browse other questions tagged .