Return to Answer

In general, you need to serve both your page and your service worker script via HTTPS in order to use service workers. The rationale is described at Prefer Secure Origins For Powerful New Features.

There's an exception to the HTTPS requirement in place to facilitate local development: if you access your page and service worker script via http://localhost[:port], or via http://127.x.y.z[:port], then service workers should be enabled without any further actions.

If, for some reason, you need to access your local web server via a hostname other than localhost or 127.x.y.z, or if you need to test things on a remote web server that doesn't support HTTPS, there is a manual workaround you can use. It involves starting up Chrome via the command line, and using both the --user-data-dir and --unsafely-treat-insecure-origin-as-secure flags.

This bug has more details, including a full example of how to launch Chrome.

Firefox offers similar functionality, via the devtools.serviceWorkers.testing.enabled setting.

Please note that this functionality is only meant to facilitate testing that wouldn't otherwise be able to take place, and you should always plan on using HTTPS when serving the production version of your site. Don't ask real users to go through the steps of enabling those flags!

In general, you need to serve both your page and your service worker script via HTTPS in order to use service workers. The rationale is described at Prefer Secure Origins For Powerful New Features.

There's an exception to the HTTPS requirement in place to facilitate local development: if you access your page and service worker script via http://localhost[:port], or via http://127.x.y.z[:port], then service workers should be enabled without any further actions.

In recent versions of Chrome, you can work around this requirement duriing local development via chrome://flags/#unsafely-treat-insecure-origin-as-secure, as explained in this answer.

Firefox offers similar functionality, via the devtools.serviceWorkers.testing.enabled setting.

Please note that this functionality is only meant to facilitate testing that wouldn't otherwise be able to take place, and you should always plan on using HTTPS when serving the production version of your site. Don't ask real users to go through the steps of enabling those flags!

In general, you need to serve both your page and your service worker script via HTTPS in order to use service workers. The rationale is described at Prefer Secure Origins For Powerful New Features.

There's an exception to the HTTPS requirement in place to facilitate local development: if you access your page and service worker script via http://localhost[:port], or via http://127.x.y.z[:port], then service workers should be enabled without any further actions.

If, for some reason, you need to access your local web server via a hostname other than localhost or 127.x.y.z, or if you need to test things on a remote web server that doesn't support HTTPS, there is a manual workaround you can use. It involves starting up Chrome via the command line, and using both the --user-data-dir and --unsafety-treat-insecure-origin-as-secure flags.

This bug has more details, including a full example of how to launch Chrome.

Firefox offers similar functionality, via the devtools.serviceWorkers.testing.enabled setting.

Please note that this functionality is only meant to facilitate testing that wouldn't otherwise be able to take place, and you should always plan on using HTTPS when serving the production version of your site. Don't ask real users to go through the steps of enabling those flags!

In general, you need to serve both your page and your service worker script via HTTPS in order to use service workers. The rationale is described at Prefer Secure Origins For Powerful New Features.

There's an exception to the HTTPS requirement in place to facilitate local development: if you access your page and service worker script via http://localhost[:port], or via http://127.x.y.z[:port], then service workers should be enabled without any further actions.

If, for some reason, you need to access your local web server via a hostname other than localhost or 127.x.y.z, or if you need to test things on a remote web server that doesn't support HTTPS, there is a manual workaround you can use. It involves starting up Chrome via the command line, and using both the --user-data-dir and --unsafely-treat-insecure-origin-as-secure flags.

This bug has more details, including a full example of how to launch Chrome.

Firefox offers similar functionality, via the devtools.serviceWorkers.testing.enabled setting.

Please note that this functionality is only meant to facilitate testing that wouldn't otherwise be able to take place, and you should always plan on using HTTPS when serving the production version of your site. Don't ask real users to go through the steps of enabling those flags!

In general, you need to serve both your page and your service worker script via HTTPS in order to use service workers. The rationale is described at Prefer Secure Origins For Powerful New Features.

There's an exception to the HTTPS requirement in place to facilitate local development: if you access your page and service worker script via http://localhost[:port], or via http://127.x.y.z[:port], then service workers should be enabled without any further actions.

If, for some reason, you need to access your local web server via a hostname other than localhost or 127.x.y.z, or if you need to test things on a remote web server that doesn't support HTTPS, there is a manual workaround you can use. It involves starting up Chrome via the command line, and using both the --user-data-dir and --unsafety-treat-insecure-origin-as-secure flags.

This bug has more details, including a full example of how to launch Chrome.

Firefox offers similar functionality, via the dom.serviceWorkers.testing.enabled setting.

Please note that this functionality is only meant to facilitate testing that wouldn't otherwise be able to take place, and you should always plan on using HTTPS when serving the production version of your site. Don't ask real users to go through the steps of enabling those flags!

In general, you need to serve both your page and your service worker script via HTTPS in order to use service workers. The rationale is described at Prefer Secure Origins For Powerful New Features.

There's an exception to the HTTPS requirement in place to facilitate local development: if you access your page and service worker script via http://localhost[:port], or via http://127.x.y.z[:port], then service workers should be enabled without any further actions.

If, for some reason, you need to access your local web server via a hostname other than localhost or 127.x.y.z, or if you need to test things on a remote web server that doesn't support HTTPS, there is a manual workaround you can use. It involves starting up Chrome via the command line, and using both the --user-data-dir and --unsafety-treat-insecure-origin-as-secure flags.

This bug has more details, including a full example of how to launch Chrome.

Firefox offers similar functionality, via the devtools.serviceWorkers.testing.enabled setting.

Please note that this functionality is only meant to facilitate testing that wouldn't otherwise be able to take place, and you should always plan on using HTTPS when serving the production version of your site. Don't ask real users to go through the steps of enabling those flags!