Cross-Origin Limitations of SVG Web Fonts

Loading external web fonts inside Scalable Vector Graphics (SVG) introduces complex security and rendering challenges governed by web security standards. How a browser handles cross-origin font requests inside an SVG depends almost entirely on the method used to embed the SVG into the document. While inline SVGs adhere to standard Cross-Origin Resource Sharing (CORS) rules, SVGs embedded via image tags or CSS properties operate under a strict security sandbox that entirely blocks external network requests, including web fonts.

The Embedding Context Determines Font Loading

The primary limitation of using external fonts inside an SVG is determined by how the SVG document is rendered by the browser:

1. HTML <img> Tags and CSS Backgrounds (Strict Sandbox) When an SVG is referenced through an <img> tag, a CSS background-image, or standard CSS content properties, browsers place the SVG into an isolated, secure browsing context. In this mode, all external network requests are disabled to prevent tracking, data leakage, and cross-site scripting (XSS). Consequently, any @font-face rules referencing external URLs (such as Google Fonts or a remote CDN) will be ignored, and the browser will fall back to system fonts.

2. Inline SVG Elements When SVG markup is placed directly within an HTML document (<svg>...</svg>), it shares the parent document’s security context. External fonts declared in a <style> block using @font-face will load, provided the remote server hosting the font sends the appropriate CORS response header: Access-Control-Allow-Origin.

3. <iframe>, <object>, and <embed> Elements Embedding an SVG via <object type="image/svg+xml"> or <iframe> treats the SVG as an independent XML document. External resources, including fonts, can be fetched as long as the font server satisfies standard CORS requirements by permitting the request origin.

Cross-Origin Resource Sharing (CORS) Requirements

Web fonts are subject to strict CORS restrictions across modern browsers. When an SVG is allowed to make network requests (such as in an inline or <object> context), the font file will fail to render if:

• The font server does not supply the Access-Control-Allow-Origin header matching the host domain (or *).
• The request violates the Content Security Policy (CSP) of the host application, specifically directives such as font-src.
• The protocol changes unsafely (e.g., trying to fetch an http:// font from an https:// secure context, triggering mixed-content blocking).

Canvas Tainting and Export Restrictions

When drawing an SVG containing external assets to an HTML5 <canvas> element via JavaScript, cross-origin security rules can cause the canvas to become tainted. A tainted canvas cannot be exported using toDataURL() or getImageData(), throwing a security exception. Furthermore, if the SVG relies on external fonts that failed to load due to sandbox rules (such as loading the SVG via an Image() object), the canvas will render the text using the default fallback font instead of the intended typography.

Bypassing Limitations: Base64 Embedding

To ensure consistent typography across all embedding methods (<img>, inline, <canvas>, or CSS backgrounds) without running into cross-origin restrictions, the font must be embedded directly inside the SVG file.

By converting the font file (WOFF or WOFF2) into a Base64-encoded Data URI and placing it inside the SVG’s internal <style> element within the @font-face declaration, the SVG becomes completely self-contained:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100">
  <defs>
    <style>
      @font-face {
        font-family: 'CustomFont';
        src: url('data:font/woff2;base64,d09GMgABAAAAA...') format('woff2');
      }
      text {
        font-family: 'CustomFont', sans-serif;
      }
    </style>
  </defs>
  <text x="10" y="50">Vector Text</text>
</svg>

Converting fonts to Base64 eliminates external network dependencies, bypasses CORS restrictions entirely, and ensures identical rendering regardless of the host environment.