Use the browser’s console message and the font response together. A successful download status can still accompany a browser policy failure.
Capture the exact rejected font
Open Console and Network on the affected page. Record the font URL, page origin, status, response headers and the complete policy error with private data removed. Confirm the applied font in the rendering inspector if available. A fallback can make the page look approximately right while concealing the failure; do not judge success from the absence of a broken-image icon.
Distinguish file delivery from browser permission
Request the font directly to check whether it exists, but do not treat direct navigation as a CORS test. Browser font use is a different context. Compare the failed page request with a working font from the same provider. A missing file, certificate failure, redirect or policy mismatch requires its own correction, so avoid adding access headers until the evidence points there.
Find the header owner
Check whether the font is served by origin storage, a CDN transformation or an external font service. Apply the provider’s documented cross-origin configuration for that static resource. If it varies responses by allowed origin, consult its cache-key and Vary requirements. Do not broaden access for every application endpoint just to repair one public font asset.
Check redirects and preload alignment
Inspect the final response after redirects, because the initial host’s headers may not describe the font response. Verify that any font preload matches the actual URL, font type and applicable cross-origin behavior. Duplicate requests can indicate a mismatch. If a preload is not useful, remove it and compare the normal loading path rather than adding more directives by trial and error.
Verify both delivery and typography
Purge the affected asset only after the policy is corrected, then use a fresh load from the real page origin. Confirm no policy errors, successful use of the intended face and readable fallback during failure. Check both themes and another template using the same font. Keep the old delivery rule until the browser-based verification succeeds.
Symptom-to-cause worksheet
| What you observe | What to investigate | Next check |
|---|---|---|
| 200 response but font rejected | Cross-origin policy issue | Read Console and final response headers |
| Font URL redirects | Final host differs from CSS assumption | Inspect last response in the chain |
| Two requests for same face | Preload attributes or URLs mismatch | Compare preload with actual font request |
Worked investigation scenario
This is an illustrative case, not a measured Velonic result. Imagine a font request returns 200 from a CDN, but the browser logs a cross-origin rejection and renders fallback text. Directly opening the font URL succeeds because it does not reproduce font use from the page origin. Correct the public font response policy at the delivery owner, then test from the actual page in a fresh session. Verify the intended face is applied before calling the issue fixed.
Put it into practice
- Test font use from the page, not direct navigation alone.
- Change the static asset policy at its owning layer.
- Verify applied typography and fallback.
AI-assisted educational content prepared for the Velonic resource library. How these guides are prepared.