ScreenshotAPI Screenshots of Websites with Indian Fonts Look Wrong: Fixes

If Indian-language text is missing, substituted, or incorrectly shaped in a ScreenshotAPI screenshot, first check that the request does not set block_font=true. ScreenshotAPI documents that setting as blocking font files and forcing system default fonts; false allows custom web fonts and is the documented default. Then verify the page’s actual font rules and glyph coverage, confirm the font files load, and make sure capture happens after the page is ready. The right fix depends on the page, font, script, and endpoint version; there is no universal fix.

This guide refers to ScreenshotAPI’s documented /v3/screenshot endpoint and controls. Confirm the exact product domain and version used by your integration before copying parameters: similarly named screenshot services may have different options.

1. Check whether ScreenshotAPI is blocking fonts

Inspect the request and any shared configuration for block_font. If it is true, custom font files will not load and the page falls back to system fonts. Set it to false, or omit it if you want the documented default. See ScreenshotAPI’s resource control documentation.

// Request configuration concept: allow custom font files
{
  "url": "https://example.com/page-with-indic-text",
  "block_font": false
}

This is an option fragment, not a complete request: use the authentication and parameter format documented for the endpoint version in your application. Check proxies, wrappers, and environment-specific defaults too; a setting may be added outside the code that builds the visible request.

2. Verify the page’s CSS and font coverage

A loaded font can still be the wrong font for the affected text. In browser developer tools, inspect a broken text element and check:

• Computed family: Is the intended family first in the applied font stack?
• Weight and style: Does the page request a weight or italic face that the font source actually provides?
• Rule match: Does the selector apply to the affected element, or is a more specific rule overriding it?
• Script and character coverage: Does the selected font support the exact language, script, and characters shown?
• Fallbacks: Does the CSS provide a usable fallback when the preferred face lacks a glyph?

Google Fonts serves a stylesheet tailored to the requesting browser; the browser then downloads the appropriate font file. Check both steps. Its documentation also describes font loading behavior that varies across browsers: text can remain blank while loading in Chrome and Safari, while Firefox can show unstyled text before the font appears. See the Google Fonts technical considerations and getting-started guide.

3. Confirm the stylesheet and font requests complete

Open the page in a browser with its network panel visible, reload it, and filter for the font stylesheet and font files. Look for failed requests, blocked requests, unexpected redirects, or files that remain pending when capture begins. If the page uses self-hosted fonts, check that the URLs work from the page and that access controls permit them. If it uses a hosted font service, confirm the stylesheet and subsequent font request both succeed.

Also compare the live page with the screenshot using the same viewport and page state. If the browser itself shows fallback text, fix the page’s font delivery first. If the browser shows the intended font but the capture does not, focus on request settings, endpoint behavior, and capture timing.

4. Capture after the page has reached the right state

Some pages load fonts or render text after JavaScript runs. A screenshot taken too early can capture fallback text or blank text. Identify the event that indicates the page is ready, then configure the delay or other render option supported by the exact ScreenshotAPI endpoint version you call. ScreenshotAPI documents rendering options for pages that use JavaScript, lazy loading, or delays; check its render documentation for the parameters available to your version.

1. Reproduce the capture with the same URL and request parameters.
2. Check the page’s network panel to see when its font requests finish.
3. Determine whether the affected text appears only after a script or application state change.
4. Use the endpoint’s documented readiness or delay control to capture after that state is reached.
5. Compare repeated captures. If results vary, investigate whether font loading or page rendering is still in progress.

A longer fixed delay can help diagnose timing, but it does not fix a missing font, insufficient glyph coverage, or a failed request. Prefer a readiness condition that reflects the page’s actual state when the endpoint supports one.

5. Use injected CSS as a controlled diagnostic

ScreenshotAPI supports CSS and JavaScript injection at runtime before rendering and capture. Its help page demonstrates importing a Google Font and assigning it with CSS. You can use the same approach to test whether a known family and a targeted rule change the result. This test does not prove that every font host is reachable or that the chosen font covers the needed glyphs.

/* Diagnostic CSS example; replace the family and selector for your page. */
@import url('https://fonts.googleapis.com/css2?family=Noto+Sans+Devanagari&display=swap');

body {
  font-family: 'Noto Sans Devanagari', sans-serif;
}

Use CSS injection in the format your endpoint version documents. Compare the injected result with the original, and inspect whether the font request completed. If the injected family changes nothing, check reachability, the selector, and script coverage before changing capture settings. See ScreenshotAPI’s CSS/JavaScript injection documentation and its help page.

6. Isolate Indic shaping and layout problems

When characters are present but look broken, joined incorrectly, or spaced strangely, investigate font and CSS compatibility rather than assuming the image format caused it. The Government of India localisation guidance has a section specifically titled “CSS rendering Issues in Indic Script.” Use it as context for checking page styling and rendering behavior: Government of India localisation guidance.

For a focused comparison, create a minimal page containing the same text, font source, and relevant CSS. Compare that page in a normal browser and through the API capture. This is a debugging method, not a result established by the cited documentation. Keep the text and font constant while you vary one factor at a time: the font-blocking setting, the font rule, network access, or capture readiness.

7. Troubleshooting common symptoms

Symptom	Likely cause	What to check or change
Hindi text is missing or replaced by another font	block_font=true, failed font request, or missing glyph coverage	Allow font files, inspect stylesheet and font requests, and confirm the selected face supports the text.
Text is blank in the screenshot but appears later in a browser	Capture occurs while the web font is loading	Check font request timing and configure capture readiness using the options for your endpoint version.
Only some characters are wrong	The chosen face may not cover every character, or a fallback is being used for only part of the text	Inspect the computed family and verify coverage for the exact characters and script.
Injected CSS has no visible effect	The injected rule does not match, the font source cannot be reached, or the font lacks the glyphs	Check the selector, the font network request, and script coverage; compare with a minimal page.
Text looks joined or positioned incorrectly	Font or CSS rendering compatibility, fallback behavior, or a page-specific layout rule	Inspect computed styles and compare the same text and font on a minimal page. Do not assume the screenshot file format is responsible.
Results differ between runs	Font loading or JavaScript rendering may not be complete at capture time	Inspect request timing and page readiness, then use a suitable documented wait option.
A suggested parameter has no effect	It may belong to another product, domain, or endpoint version	Verify the exact API hostname and version. Do not copy parameters from a similarly named service without checking its identity.

8. A practical diagnostic checklist

1. Record the exact API hostname, endpoint path, version, URL, and relevant parameters.
2. Check that block_font is false or omitted where the documented default applies.
3. Inspect computed family, weight, style, selector matching, fallback, and script coverage for the affected element.
4. Confirm the font stylesheet and font file both load successfully.
5. Check whether JavaScript or delayed font loading means the page needs a readiness condition before capture.
6. Try a targeted CSS injection as a controlled comparison, using the syntax supported by the endpoint version.
7. If the issue remains, compare a minimal page with the same text, font, and CSS in the browser and API capture.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server for developers. Make a screenshot with one request; see the ScreenshotNeo API documentation for request options and configuration:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com/page-with-indic-text -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://example.com/page-with-indic-text"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://example.com/page-with-indic-text'
});
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);

ScreenshotNeo removes cookie banners, popups, and chat widgets before the shot; each of those steps can be turned off. Bot checks, blank pages, and failed loads are never billed, and response headers say what happened. Its MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. Visit ScreenshotNeo to learn about the service, or sign up free.

Performance, reliability, and cost considerations

• Performance: Font downloads and page scripts add work before capture. A readiness condition can improve consistency, while an unnecessarily long fixed delay increases wait time. Check actual page and font behavior when choosing the wait option.
• Reliability: A screenshot can faithfully capture a fallback font if the page has not loaded its intended face. Treat the screenshot and the browser network/style inspection as evidence about different stages: capture output alone may not show why a font was unavailable.
• Cost: No verified ScreenshotAPI pricing or billing behavior is included in the sources for this guide. Check the terms for the exact service and account before increasing delays or retry volume. For ScreenshotNeo, only clean shots are billed; bot checks, CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing.

Frequently asked questions

Does changing PNG to JPEG fix Indic text?

The available evidence points first to font loading, CSS, glyph coverage, and capture timing. Check those before treating the output image format as the cause.

Is a Google Font guaranteed to fix the page?

No. A test font can help isolate the cause, but the font must be reachable, applied to the relevant elements, and cover the required characters.

Can I use a parameter from another ScreenshotAPI-branded site?

Only after verifying that it belongs to the same product and endpoint you use. The name alone does not establish compatible controls.

Where can I find guidance on Indic script rendering?

The Government of India localisation guidance includes a section on CSS rendering issues in Indic script; it can inform diagnosis, but it does not establish one fix for every page or capture service.