HTTPs Compatibility

HTTPS Compatibility

Canvas works over HTTPS out of the box. The one thing to watch for is mixed content: an HTTPS page that loads an asset over plain http://. Browsers block or warn on those requests, which can break images, fonts, scripts, or styles.

Use HTTPS for every asset

The safest rule is to load every third-party asset over https://. For example, the Google Fonts link in Canvas already uses HTTPS:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link href="https://fonts.googleapis.com/css2?family=Inter:wght@300;400;500;600;700&display=swap" rel="stylesheet">

If you copy a snippet from somewhere that uses http://, change it to https:// before using it:

<!-- Avoid: triggers a mixed-content warning on an HTTPS page -->
<link href="http://fonts.googleapis.com/css?family=Heebo:400,500,700" rel="stylesheet">

<!-- Prefer -->
<link href="https://fonts.googleapis.com/css?family=Heebo:400,500,700" rel="stylesheet">

Protocol-relative URLs

If an asset host serves both HTTP and HTTPS, you can drop the protocol entirely and let the browser match the page. The URL then works on either scheme:

<img src="//cdn.example.com/images/photo.jpg" alt="Photo">

The browser requests it over HTTPS when the page is HTTPS, and over HTTP otherwise.

Local assets are already safe

Canvas references its own files with relative paths, which inherit the page protocol automatically:

<link rel="stylesheet" href="style.css">
<script src="js/functions.bundle.js"></script>

These never cause a mixed-content problem because they resolve to the same origin as the page.

Tips

• Audit any third-party embed (analytics, maps, chat widgets) for http:// URLs and switch them to https://.
• Open your browser's developer console after going live. Mixed-content issues are reported there as blocked or insecure requests.
• Prefer explicit https:// over protocol-relative URLs when you know the host supports HTTPS, since it is clearer and works even when a page is opened from a local file.