How to Fix Screenshot API Captures with Missing Hindi Text

If a screenshot API omits Hindi text or shows empty squares, first check whether the text exists in the page DOM. If it does, the usual diagnostic branches are missing Devanagari glyph coverage in the capture environment or a screenshot taken before the page’s web fonts finish loading. Waiting for fonts fixes a timing race; it cannot supply a font that the browser does not have.

1. Find out whether the page contains the Hindi text

Inspect the rendered page in the same environment that makes the screenshot request. Check the element’s textContent or use the browser automation framework’s DOM inspection. Compare that with the screenshot:

Hindi is absent from the DOM: investigate the page’s data, localization, hydration, or rendering logic. Font installation will not restore content that the page never rendered.
Hindi is in the DOM but missing or replaced in the image: check glyph coverage, font loading, and whether the capture runtime matches the environment where the page looks correct.

Also check whether the text is clipped, covered by another element, or styled with visibility, display, opacity, or a color that blends into the background. Those are page-layout issues rather than missing-glyph issues.

2. Check Devanagari font coverage in the capture runtime

Hindi is written in Devanagari. The browser needs access to a font that contains the glyphs used by the page. A developer’s desktop may have suitable fonts installed even when a Linux container, CI runner, or serverless image does not, so check the exact runtime that launches the browser.

On Debian-family systems, the fonts-noto-core package includes Noto Sans Devanagari and Noto Serif Devanagari font files. Install the appropriate font package in the image that runs the browser, then rebuild or redeploy that image. Package names and commands vary by distribution and image version; check that distribution’s package documentation and confirm the font is visible to the browser.

If the site supplies its own Hindi web font, confirm that its font request succeeds and that the font’s character coverage includes the text. A CSS declaration naming a font does not guarantee the file loaded. If the requested face cannot render a character, the browser may use a fallback font, which may also lack the needed glyph.

3. Wait for web fonts before taking the screenshot

A capture can happen after the page content appears but before a web font has loaded and affected layout. In Playwright, wait for the page’s font set before calling screenshot():

import { chromium } from 'playwright';

const url = process.argv[2];
if (!url) throw new Error('Usage: node capture.mjs <url>');

const browser = await chromium.launch({ headless: true });
try {
  const page = await browser.newPage({ viewport: { width: 1440, height: 1000 } });
  await page.goto(url, { waitUntil: 'networkidle', timeout: 60000 });
  await page.evaluate(() => document.fonts.ready);
  await page.screenshot({ path: 'capture.png', fullPage: true });
} finally {
  await browser.close();
}

Save this as capture.mjs in a project with Playwright installed, then run node capture.mjs https://example.com. The page-font wait is await page.evaluate(() => document.fonts.ready); the rest is a minimal runnable capture flow. MDN documents that document.fonts.ready resolves after document fonts have loaded, layout work is complete, and no further font loads are needed. It is a readiness check, not a font installer.

When the site does not use a web font

If the page relies on system fonts, waiting for document.fonts.ready may not solve missing glyphs. Install a suitable Devanagari font in the capture image or configure the page to load a font with the required coverage. Then wait for that font to be ready before capture.

When network-idle waiting is a poor fit

Some pages keep connections open or continually request resources, so networkidle may time out or delay capture unnecessarily. In that case, wait for the page’s main content or a specific font-dependent element, then await document.fonts.ready. A fixed delay can be a fallback for a known animation or delayed update, but it is less reliable than waiting for the actual condition.

4. Reproduce the production browser conditions

Keep the operating-system image, browser family and version, installed fonts, browser settings, and headless mode aligned when comparing local and production captures. Browser rendering can vary with the host OS, browser version, settings, hardware, power source, and headless mode. Playwright recommends generating and comparing screenshots in the same environment when visual consistency matters.

Record these details when investigating a failure: container or runner image, browser and automation-library versions, font packages, page URL, viewport, device scale factor, locale, and whether the run is headless. This makes it easier to tell an environment difference from a page change.

5. Diagnose common failure patterns

Symptom	Likely cause	What to do
Empty squares or replacement symbols	The selected font or fallback fonts lack one or more Devanagari glyphs.	Check fonts in the actual capture image; install or load a font with the needed coverage.
Hindi is missing only in automated captures	The automation image has different fonts, browser settings, or a different browser version from the desktop.	Inspect and align the capture runtime; reproduce the issue in that same image.
Text is correct after refresh but wrong in the screenshot	The screenshot was taken before a web font or page update finished.	Wait for the relevant content, then await `document.fonts.ready`.
DOM inspection finds no Hindi text	Page data, localization, or client-side rendering did not produce the text.	Debug the application’s content and rendering path before changing fonts.
Browser will not launch in Linux	Browser runtime dependencies may be missing.	Follow the automation framework’s current Linux system requirements. Browser shared libraries and font glyph coverage are separate concerns.
Waiting for network idle hangs or times out	The page keeps network activity open or active.	Wait for a relevant selector or application-ready condition, then wait for fonts.
Only some Hindi characters fail	The chosen font may have partial coverage, or the page may use different font faces for different weights or elements.	Check the failing characters and the computed font for each affected element; verify coverage for the actual text and styles.

6. Keep captures reliable and control their cost

Font readiness can add time when a font is slow or unavailable, so ensure font URLs are reachable from the capture environment and avoid waiting on unrelated page activity. Prefer an explicit readiness condition over an arbitrary long sleep. If a provider offers request logs or response headers, use them to distinguish navigation failures and timeouts from successful captures with a rendering problem.

For repeatable output, pin the browser/runtime image and font package versions you deploy, and compare screenshots from that same environment. A hosted screenshot API removes the need to maintain your own browser image, but it cannot make a page’s missing DOM content appear; verify the page itself and the provider’s documented font behavior for your case.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. Its API captures a URL in one request, so you do not have to install and maintain Playwright and a browser image for this capture. The API also accepts and removes cookie consent banners, newsletter popups, and chat widgets before the shot. Bot checks, blank pages, and failed loads are never billed, and response headers report the page verdict and billing status. AI agents can use its MCP server tools, including take_screenshot, get_page_info, and capture_pdf.

For a Hindi rendering issue, still verify that the page has the right text and font available; a screenshot API does not fix missing page content or missing glyphs. See the ScreenshotNeo API documentation for request options.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
r.raise_for_status()
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 import('node:fs/promises').then(fs => fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer())));

Free includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. Sign up for 1,000 free screenshots a month, with no card.

FAQ

Will changing the screenshot format fix missing Hindi?

PNG, JPEG, and WebP encode rendered pixels; changing formats does not add missing font glyphs. Fix rendering before changing output format.

Can a Unicode setting make Hindi appear?

Unicode text encoding does not provide font glyphs. Check that the text is present and that a suitable font can render it.

Does a successful API response prove the Hindi rendered correctly?

No. A successful image response means an image was returned; inspect the result or page rendering when validating language-specific text.

Should I bundle a font with my application?

That can make font availability more predictable if the page loads the bundled font successfully and it covers the needed characters. The capture still needs to wait for it before taking the screenshot.