# Chrome "Not secure" in the address bar: causes and fixes

> Chrome labels a page Not secure when it loads over plain HTTP or after a certificate warning was bypassed. How to tell which and how to remove it.

Source: https://ssl.sh/errors/chrome-not-secure-warning/
Last updated: 2026-11-10

**"Not secure" in Chrome's address bar means the page is not using a private connection.** Usually the page loaded over plain `http://`, so the traffic is not encrypted. A red label on an `https://` address means the connection is not trusted, typically after someone clicked past a certificate warning. The site owner fixes it by enabling HTTPS.

## What the indicators mean

Chrome's help page describes three states for the icon left of the address:

| Indicator | Meaning |
|---|---|
| Default (tune icon) | Private connection; information sent or received is private between you and the site |
| Info icon or grey "Not secure" | "The site doesn't use a private connection" (plain HTTP) |
| Red "Not secure" or "Dangerous" | "Not secure: Proceed with caution" means the connection is not private; "Dangerous" is a Safe Browsing block |

Chrome 117 (September 2023) replaced the padlock with a neutral tune icon for secure pages, so the absence of a warning, not a padlock, is now the normal state.

## How the label evolved

- **Chrome 68, July 2018:** all HTTP pages show "Not secure".
- **Chrome 70, October 2018:** the label turns red when a user types into a form on an HTTP page.
- **Chrome 80 onwards:** mixed audio and video, and later images, are automatically upgraded to HTTPS and blocked if they fail, instead of only downgrading the indicator.
- **Chrome 147, April 2026:** Google's plan enables "Always Use Secure Connections" for public sites for Enhanced Safe Browsing users.
- **Chrome 154, October 2026:** Google announced that the same setting would turn on by default for all users, so Chrome asks for permission before the first visit to any public site without HTTPS.

## Common causes, most frequent first

### 1. The site has no HTTPS at all

The server only listens on port 80 or has no certificate. Confirm:

```bash
curl -sI https://example.com/ -o /dev/null -w '%{http_code}\n'
```

A connection error or a certificate failure means HTTPS is not set up.

### 2. HTTPS exists but HTTP is not redirected

The site works at `https://example.com` but old links, bookmarks, search results or a typed address land on `http://`. Confirm that HTTP answers with a redirect:

```bash
curl -sI http://example.com/ | grep -iE '^(HTTP|location)'
```

A `200` instead of `301`/`308` with `Location: https://...` means visitors can stay on HTTP.

### 3. A certificate warning was bypassed

On an `https://` address, a red "Not secure" means the encrypted connection is not trusted. You typically see it after clicking "Proceed" on a warning such as [Your connection is not private](https://ssl.sh/errors/your-connection-is-not-private/). The certificate is expired, untrusted or for another name. Check it with the [SSL checker](https://ssl.sh/tools/ssl-checker/).

### 4. Private devices and internal tools

Routers, printers, NAS boxes and intranet apps reached by `http://192.168.x.x` or a short internal name are labelled Not secure. Public CAs do not issue certificates for private IP addresses or internal names; use a real domain with DNS validation, or an internal CA trusted by your devices.

### 5. Mixed content and insecure forms

An HTTPS page that submits a form to an `http://` URL triggers a warning, and HTTP subresources are upgraded or blocked. Modern Chrome rarely downgrades the address bar for this, but the page may break. Scan for it with the [mixed content scanner](https://ssl.sh/tools/mixed-content-scanner/) and see [mixed content warnings](https://ssl.sh/errors/mixed-content-warning/).

## What visitors can do

You cannot fix the site, but you can lower the risk. Try typing `https://` in front of the address; many sites support HTTPS but do not redirect. Do not enter passwords, card numbers or personal data while the label is shown. If the label appeared on a site that is normally fine, check whether you are on public Wi-Fi with a login page, or whether security software is intercepting connections, and compare on mobile data.

## How site owners fix it

Serving the site over HTTPS with a valid certificate, and redirecting all HTTP to it, removes the label.

**1. Get a certificate.** On Nginx or Apache with Certbot:

```bash
sudo certbot --nginx -d example.com -d www.example.com
```

Full walkthrough: [Nginx with Let's Encrypt](https://ssl.sh/guides/nginx-lets-encrypt-certbot/). Hosting panels and cloud load balancers have their own certificate settings.

**2. Redirect all HTTP to HTTPS** with a permanent redirect:

```nginx
server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}
```

Other servers are covered in [redirect HTTP to HTTPS](https://ssl.sh/guides/redirect-http-to-https/).

**3. Update internal links and canonical URLs** to `https://`, and fix any `http://` subresources.

**4. Add HSTS** once HTTPS is stable, so browsers never try HTTP again: see [enable HSTS](https://ssl.sh/guides/enable-hsts/).

## How to verify the fix

1. `curl -sI http://example.com/` returns `301` with an `https://` `Location`.
2. Opening `example.com` in a new private window lands on `https://` with the tune icon and no "Not secure" text.
3. The [mixed content scanner](https://ssl.sh/tools/mixed-content-scanner/) reports no insecure resources or form targets.
4. `curl -sI https://example.com/ | grep -i strict-transport-security` shows the HSTS header if you enabled it.