How to Fix Missing Devanagari Text in Microlink Screenshots
Hindi and other Devanagari text can disappear from screenshots when it is missing from the page, its font has no matching glyphs, or capture happens too early. Diagnose each layer and apply a targeted fix.
Missing Hindi or other Devanagari text in a Microlink screenshot usually points to one of three things: the text is not in the rendered page yet, the selected font cannot draw the characters, or the screenshot is taken before the content or font finishes loading. Check those separately before changing your Microlink request. A screenshot captures what the browser rendered; it cannot restore text that the page never produced.
Microlink supports screenshot capture and offers waitForSelector to wait for a page element. Its browser automation features also document scripts and styles that can shape a page before capture. These controls help diagnose rendering and timing; they do not establish which fonts are installed in Microlink’s current browser runtime. See the Microlink Screenshot API documentation, its guide to waiting for dynamic content, and its Browser Automation API documentation.
1. Find out whether the text exists in the page
- Open the exact URL that Microlink captures in a regular browser, at the same route and with the same relevant query parameters.
- Inspect the element that should contain the Devanagari text. Check whether the expected characters are present in the DOM, rather than relying only on what you see visually.
- Check whether the element is hidden, empty, covered by a loading state, or populated only after client-side JavaScript runs.
If the text node is absent, look at the site’s data, API response, JavaScript hydration, and visibility logic. A font change cannot fix missing content. If the text node exists but shows blank space, boxes, or unexpected symbols, investigate the font. If the text appears after a delay, investigate capture timing.
2. Check font selection, coverage, and loading
Inspect the text element’s computed font-family and the browser’s rendered-font information, if available. A CSS family name only describes the requested stack; it does not prove that the corresponding font file loaded or contains the needed Devanagari glyphs. In the browser’s network panel, check font requests for failures, blocked cross-origin requests, or responses that arrive after the page has otherwise rendered.
When you control the site, serve a font with Devanagari coverage and include it in the relevant stack. For example, adapt this illustrative CSS to a font file that your site is authorized to serve:
@font-face {
font-family: "Site Devanagari";
src: url("/fonts/site-devanagari.woff2") format("woff2");
font-style: normal;
font-weight: 100 900;
font-display: swap;
}
.article-copy {
font-family: "Site Devanagari", "Noto Sans Devanagari", sans-serif;
}The URL and family above are placeholders, not a Microlink-specific recipe. Verify that the capture browser can reach the font URL and that the font has the required glyphs. If a third-party font host is involved, check its access rules and cross-origin configuration. Prefer a font served from the page’s own origin when you can, so the screenshot browser can fetch it under the same conditions as the page.
3. Wait for the actual text element in Microlink
For JavaScript-rendered content, use Microlink’s documented waitForSelector option with a selector for the element that holds the Devanagari text. A generic page load event may happen before an application has finished fetching data or rendering the relevant section. Follow Microlink’s current parameter syntax in its documentation; do not assume a selector wait also proves that a webfont has loaded.
Choose a selector that represents usable content, such as the article heading or text container, rather than a generic body element that exists before hydration. If the text is inserted into the same element after it first appears, test whether waiting for that selector is sufficient for your page. When it is not, use a more specific ready-state selector or a tested delay supported by your capture setup.
4. Test font readiness when timing is still suspect
After confirming the text exists and its font has coverage, compare a normal capture with one that waits for font readiness. Microlink documents browser script injection as an automation capability. A readiness check you can test in a browser context is:
await document.fonts.ready;This is a diagnostic idea to validate on the actual page and in the supported Microlink automation configuration. The cited Microlink materials do not guarantee this exact script as a ready-to-use API recipe, so confirm the injection syntax and behavior in its documentation. Also remember that font readiness only describes fonts the document has attempted to load; it cannot make an unavailable or incomplete font gain glyphs it does not contain.
5. Account for Chromium and runtime differences
Chromium’s source history includes a March 4, 2026 change adding default font-family mappings for Devanagari. The change describes earlier generic system-font fallback as a problem and lists Linux mappings including Noto Sans Devanagari for standard and sans-serif, Noto Serif Devanagari for serif, and Noto Sans Mono for fixed-width. See the Chromium source change.
This source change does not tell you which Chromium build or fonts Microlink currently runs. Do not infer Microlink’s live runtime configuration from Chromium’s platform defaults. If the same page renders differently in your local browser and a hosted capture, provide a page-served font and verify it loads in the hosted environment.
6. Use this decision table
| What you observe | Likely layer | First action |
|---|---|---|
| Expected characters are absent from the DOM | Application data or rendering | Inspect data fetching, hydration, and content visibility. |
| Text exists but shows boxes, blanks, or fallback glyphs | Font selection, coverage, or network loading | Inspect the computed and rendered font, then check font requests and glyph coverage. |
| Text appears in a normal browser only after a delay | Asynchronous content | Wait for a selector that indicates the real content is ready. |
| Content is present but the capture has incomplete glyphs | Font-loading timing or runtime difference | Compare a capture with a validated font-readiness check; serve a suitable font from the page if needed. |
| Local and hosted captures differ despite the same URL | Environment, access, or browser configuration | Check font URL reachability and avoid assuming the hosted browser has the same system fonts. |
7. Troubleshooting common failures
| Symptom | Likely cause | Fix |
|---|---|---|
| Text is completely absent | The page did not receive or render the content. | Inspect the DOM and the site’s data or hydration path before changing CSS. |
| Characters appear as square boxes | The chosen font may not contain the glyphs, or the intended font did not load. | Verify glyph coverage and successful font requests; serve a known Devanagari-capable font. |
| Text is blank in the screenshot but appears locally | The capture browser may not reach the font host, may use a different fallback, or may capture before loading finishes. | Check font network access in the capture environment, serve the font with the page, and test a readiness wait. |
| A selector wait does not change the screenshot | The selector may exist before its text is populated, or the issue may be font-related. | Use a selector tied to ready content and separately inspect the font and its loading state. |
| A font-ready check changes nothing | The font may have loaded without Devanagari glyphs, or the page may never request the intended font. | Verify the rendered font and font file coverage; readiness cannot correct content or coverage problems. |
| A CSS family name appears correct, but glyphs still fail | The browser can fall back per glyph, and the named file may be unavailable or incomplete. | Inspect the actual rendered font for the affected characters and confirm the font file contents. |
8. Keep captures reliable and efficient
- Wait for a meaningful condition. A selector tied to the text is generally more robust than an arbitrary long delay, and avoids capturing while the application is still empty.
- Keep waits bounded. If content or fonts can fail to load, a timeout should produce a clear diagnostic rather than leave a capture request waiting indefinitely. Use the timeout controls documented for your Microlink request.
- Compare one variable at a time. First test the page’s DOM, then font loading, then the wait behavior. Changing all three together makes the cause harder to identify.
- Check the exact route and access conditions. Auth, redirects, locale, and query parameters can change which text the capture page renders.
- Cost and retries. The dossier does not establish Microlink pricing, retry behavior, or runtime guarantees. Check Microlink’s current official documentation and plan terms for those details rather than assuming a failed or repeated capture is free.
Or skip the browser setup
ScreenshotNeo is a website screenshot API and MCP server for developers. It will not repair missing page content or add Devanagari glyphs to a font, so verify the page and font first. When the page renders correctly and you want a clean capture without managing browser setup, one GET request returns an image or PDF. See the ScreenshotNeo API documentation.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpimport requests
r = requests.get(
"https://api.screenshotneo.com/v1/shot",
params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
timeout=90,
)
open("shot.webp", "wb").write(r.content)const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);Replace the example URL with your page. ScreenshotNeo accepts consent banners like a visitor and removes 60+ known consent platforms, newsletter popups, and chat widgets before capture; each of those steps can be turned off. Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers report the page verdict and billing status. Its MCP server gives AI agents tools for screenshots, page information, and PDF capture. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 shots.
Sign up free for 1,000 screenshots a month, no card required.
FAQ
Does missing Devanagari text mean Microlink is broken?
Not by itself. First determine whether the text exists in the DOM, whether a loaded font can draw it, and whether capture happened after it was ready.
Will installing a font on my own computer change a hosted screenshot?
Do not assume so. A hosted browser may run in a different environment. Serving a suitable webfont through the page gives you a way to verify that the capture browser can request it.
Does the Chromium Devanagari mapping change prove Microlink has those fonts?
No. It documents Chromium’s platform mappings in that source change, not Microlink’s current browser build or installed font files.
Can a wait fix a font with missing glyphs?
No. A wait can help when content or a font is still loading. A font without the needed glyphs requires a font with appropriate coverage.
