{
"$type": "site.standard.document",
"bskyPostRef": {
"cid": "bafyreidmdtok5pldazjwzgpn6fqtvkq4vc536yrkezerdsfx2325s243f4",
"uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3mpbsw3gwrob2"
},
"coverImage": {
"$type": "blob",
"ref": {
"$link": "bafkreibha6qxtaw4nb3eosfqj6ecfpeamw4iefcgfcsu2f75zksdrprfxi"
},
"mimeType": "image/webp",
"size": 73066
},
"path": "/ktg0215/how-to-detect-which-font-is-actually-rendering-in-a-browser-not-just-the-css-stack-12cd",
"publishedAt": "2026-06-27T15:17:35.000Z",
"site": "https://dev.to",
"tags": [
"webdev",
"css",
"javascript",
"fonts",
"Japanese Font Finder",
"@font-face"
],
"textContent": "`getComputedStyle(element).fontFamily` returns the CSS declaration: `\"Hiragino Kaku Gothic ProN\", \"Yu Gothic\", \"Noto Sans JP\", sans-serif`. That's not the font that rendered. It's a priority list. The browser picks the first one that's available and contains a glyph for the character being rendered.\n\nFor Latin text, this distinction usually doesn't matter — Windows, macOS, and Linux have converged on a small set of common system fonts. For Japanese, it matters enormously. The visual weight, stroke contrast, and letterform style of Hiragino, Yu Gothic, and Noto Sans JP are genuinely different. A site designed on macOS (where Hiragino is the system Japanese font) looks different on Windows (where Yu Gothic is the fallback).\n\nHere's how to figure out what's actually rendering, and what I learned building Japanese Font Finder to automate it.\n\n## Why `getComputedStyle` Doesn't Answer the Question\n\n`getComputedStyle(el).fontFamily` gives you the cascade result — what the browser received after applying all CSS rules. But it doesn't tell you which entry in the stack was selected.\n\nThe underlying question is: does this font exist on this system, and does it have a glyph for this specific character?\n\nFor Japanese, both conditions matter. A font might exist on the system but only cover a subset of kanji (common with CJK fonts that split across multiple files). The browser will use that font for characters it covers, and fall back for others.\n\n## Canvas-Based Font Detection\n\nThe classical technique uses a `<canvas>` element to measure text rendered with each font in the stack:\n\n\n\n function getFallbackWidth(canvas, char) {\n const ctx = canvas.getContext('2d');\n ctx.font = `16px monospace`; // known-available baseline\n return ctx.measureText(char).width;\n }\n\n function testFont(fontName, char) {\n const canvas = document.createElement('canvas');\n const ctx = canvas.getContext('2d');\n ctx.font = `16px \"${fontName}\", monospace`;\n return ctx.measureText(char).width;\n }\n\n function isAvailable(fontName, testChar = '中') {\n const canvas = document.createElement('canvas');\n const baseline = getFallbackWidth(canvas, testChar);\n const withFont = testFont(fontName, testChar);\n return withFont !== baseline;\n }\n\n\nThe idea: if the font you requested is not available, the browser falls back to `monospace`. If the width differs from the `monospace` width, the requested font was used. If it's the same, it wasn't found.\n\nThe weakness: fonts can have identical glyph widths for certain characters by coincidence. You need to test multiple characters to reduce false positives, and some edge cases remain.\n\n## The `document.fonts` API\n\nModern browsers expose a CSS Font Loading API that's cleaner for checking font availability:\n\n\n\n async function isFontLoaded(fontName) {\n await document.fonts.ready;\n return document.fonts.check(`16px \"${fontName}\"`);\n }\n\n\n`document.fonts.check()` returns `true` if the font is loaded and ready to use. But it has a subtlety: it only considers fonts that have been _requested_ — either via `@font-face` declarations or because text using that font has actually rendered. System fonts often register as available without needing an explicit load.\n\nFor web fonts, you can iterate the loaded FontFaces:\n\n\n\n async function getLoadedWebFonts() {\n await document.fonts.ready;\n const fonts = [];\n document.fonts.forEach(face => {\n fonts.push({\n family: face.family,\n weight: face.weight,\n style: face.style,\n status: face.status, // 'loaded' | 'loading' | 'error'\n source: face.toString(), // includes the URL for web fonts\n });\n });\n return fonts;\n }\n\n\nThis gives you the web fonts. System fonts won't appear here.\n\n## Combining Both Approaches for an Element\n\nTo find the actual font rendering on a specific element, you need to:\n\n 1. Get the computed font stack for the element\n 2. Parse the font family list\n 3. Check each font in order until you find one that's available\n\n\n\n\n function parseComputedFontFamilies(element) {\n const computed = getComputedStyle(element).fontFamily;\n // CSS font-family values can be quoted or unquoted, comma-separated\n return computed.split(',').map(f => f.trim().replace(/^[\"']|[\"']$/g, ''));\n }\n\n async function resolveActualFont(element) {\n const families = parseComputedFontFamilies(element);\n\n // First pass: check document.fonts (catches web fonts)\n await document.fonts.ready;\n for (const family of families) {\n if (document.fonts.check(`16px \"${family}\"`)) {\n return { family, source: 'css-font-loading-api' };\n }\n }\n\n // Second pass: canvas fingerprinting for system fonts\n const testChar = getTestChar(element); // pick a char from the element's text\n for (const family of families) {\n if (isAvailable(family, testChar)) {\n return { family, source: 'canvas-fingerprint' };\n }\n }\n\n return { family: families[families.length - 1], source: 'fallback' };\n }\n\n\nFor the test character, using a character actually present in the element text gives the most accurate result — a font might have Latin coverage but not CJK coverage.\n\n## The Character-Level Problem\n\nFont resolution in browsers is actually per-character, not per-element. A single `<p>` element mixing Latin and Japanese text might render Latin characters in one font and kanji in another, even within the same `font-family` declaration.\n\n\n\n <p style=\"font-family: 'Helvetica Neue', 'Hiragino Kaku Gothic ProN', sans-serif;\">\n Hello 世界\n </p>\n\n\n\"Hello\" renders in Helvetica Neue (Latin coverage). \"世界\" renders in Hiragino Kaku Gothic ProN (Helvetica Neue has no CJK glyphs). Two fonts, one element.\n\nTo handle this accurately, you'd need to test per-character range. In practice, JFF uses a heuristic: test with a representative CJK character for Japanese text, and with a Latin character for mixed content.\n\n## Content Script Constraints\n\nIf you're building this into a Chrome extension content script, a few constraints apply:\n\n**Canvas is available** : Content scripts can create DOM elements including canvas. No issues.\n\n**`document.fonts` is available**: The content script shares the page's window context, so `document.fonts` reflects fonts loaded on the page.\n\n**No access to font files** : Content scripts can't read font binary data from the OS or from remote font URLs. You can detect that \"Hiragino Kaku Gothic ProN\" is rendering, but you can't read the font's metadata from within the content script.\n\n**For font metadata** : Build a local lookup table. Japanese Font Finder ships a static JSON database of ~300 Japanese fonts with their vendor, category, license type, and commercial links. When a font is identified, it's looked up in the database. No API call required.\n\nThe full implementation is in Japanese Font Finder — hover any text on a Japanese page to see the resolved font with metadata. Free on Chrome Web Store.\n\nWhat's the hairiest font detection edge case you've run into? The character-level fallback mixing is what bit me most — Japanese + emoji in the same element is a particular mess.",
"title": "How to Detect Which Font Is Actually Rendering in a Browser (Not Just the CSS Stack)"
}