How to Capture Hindi Webpages with ScreenshotMachine CLI Without Broken Fonts
Fix missing or broken Devanagari text in screenshots by checking where the browser runs, whether its fonts cover the page, and when web fonts load.
If Hindi text is missing, blank, or shown as boxes in a screenshot, first check whether the page itself renders it correctly. Then identify where the capturing browser runs and confirm that it can access a font with the needed Devanagari glyphs. If you control the browser, wait for web fonts to finish loading before capture. ScreenshotMachine’s documented command-line example is a curl request to its hosted API; the reviewed docs do not describe installing fonts in that hosted renderer, so installing a font on the machine running curl is not a documented fix.
This guide shows the documented ScreenshotMachine request shape, explains its relevant settings, and gives a local-browser workflow for cases where you control the rendering environment.
1. Diagnose where the Hindi text disappears
Separate page-content problems from screenshot-rendering problems before changing settings:
- Open the target page normally and inspect the Hindi text. If it is absent there too, investigate the page’s content, localization, or application rendering.
- If the page shows Hindi correctly but the screenshot has blanks, replacement boxes, or incorrect characters, investigate the capture browser’s fonts and font-loading timing.
- Determine whether the browser is hosted by a screenshot service or runs in an environment you manage. With a hosted API, your local operating-system fonts generally do not establish what fonts are installed in the provider’s renderer.
“Hindi text missing in screenshot,” “Devanagari font missing,” and “Hindi characters show as boxes” are useful descriptions of the symptoms to search for in logs and support material. They are not evidence of how common a particular cause is.
2. Make a ScreenshotMachine API capture
ScreenshotMachine documents an HTTP GET API and a Bash example that uses curl. This is a shell client for a hosted screenshot service, not evidence of a locally installed ScreenshotMachine browser binary. The sample below uses the documented request pattern and example-style settings; substitute your key and target URL. See the ScreenshotMachine API documentation for its current parameter details.
#!/usr/bin/env bash
set -euo pipefail
CUSTOMER_KEY="YOUR_CUSTOMER_KEY"
TARGET_URL="https://example.com/hi/"
curl --fail --silent --show-error --get \
"https://api.screenshotmachine.com" \
--data-urlencode "key=${CUSTOMER_KEY}" \
--data-urlencode "url=${TARGET_URL}" \
--data-urlencode "dimension=1366x768" \
--data-urlencode "device=desktop" \
--data-urlencode "format=png" \
--data-urlencode "cacheLimit=0" \
--data-urlencode "delay=2000" \
--data-urlencode "zoom=1" \
--data-urlencode "accept-language=hi-IN,hi;q=0.9,en;q=0.8" \
--output hindi-page.png
file hindi-page.png
Use the endpoint and required key parameter exactly as shown in the provider’s documentation for your account. The documentation’s shell example sets a customer key, URL, dimensions, device, format, cache limit, delay, and zoom, encodes the values, calls the hosted API, and saves the response. The values above illustrate a request; they are not required settings for every page. Check the current provider docs for exact accepted parameter names and value formats before adapting the example.
What the request controls do
| Control | What it affects | What it does not establish |
|---|---|---|
accept-language |
The HTTP Accept-Language request header; useful when a site chooses localized content from that header. |
It does not install a font or guarantee the page will switch languages. The application may use another locale signal. |
delay |
A wait before capture, as documented by the service. | It is not a documented check that a particular web font loaded, nor a font installation control. |
dimension |
Requested capture dimensions. | It does not change glyph coverage. A narrow viewport can affect responsive layout and what is visible. |
device |
The requested device mode. | It does not select a Devanagari typeface. |
format |
Output image format. | It does not repair missing glyphs; PNG is convenient for inspecting text edges. |
cacheLimit |
Cache behavior according to the API’s documented setting. | A cached capture may not reflect a font or page change. Consult the provider docs for the exact semantics. |
zoom |
Capture scale/zoom behavior supported by the service. | Zoom cannot supply missing glyphs. It can change text size and layout. |
A longer delay can help only if the page needs additional time before it is ready. The ScreenshotMachine documentation reviewed for this guide does not promise that delay waits for a specific font, and a fixed sleep cannot verify font availability.
3. If you control the browser, verify font coverage and readiness
In a browser runtime you manage, the font must both be accessible to the browser and contain the Devanagari characters present on the page. The page may use a web font that is still downloading, a fallback that lacks some glyphs, or a system font that is absent from a minimal container.
MDN documents document.fonts as the document’s FontFaceSet. Its ready promise resolves after font loading and associated layout operations have completed. Waiting for it addresses a timing issue; it cannot provide a missing font file or add glyph coverage. See MDN: Document.fonts and MDN: FontFaceSet.ready.
// Run inside the page context in browser automation you control.
await document.fonts.ready;
// Optional diagnostic: inspect whether a particular face is available.
const hasNoto = document.fonts.check('16px "Noto Sans Devanagari"');
console.log({ hasNoto, status: document.fonts.status });
The font name in the diagnostic is only an example. Use the actual CSS family declared by the page, and verify glyph coverage for the text you need. A successful readiness wait does not prove that the selected font contains every character: the browser may have completed loading and still render some glyphs with fallback fonts.
Install fonts in a managed Linux runtime
For a browser running in a Debian-based local or CI image, check the installed font packages and the image’s package/version documentation. Debian Bookworm lists fonts-noto-core as a system font package that may be relevant to investigate; that does not establish which font package a particular page needs, nor that ScreenshotMachine uses this package.
# Example for a Debian Bookworm environment you administer.
sudo apt-get update
sudo apt-get install -y fonts-noto-core
fc-cache -f
fc-list : family | sort | grep -i 'noto'
Package availability and included font files can vary with the distribution image and version. Check the package contents, rebuild or restart the browser environment if needed, and confirm the actual family and glyph coverage. Do not assume that installing a package on the curl client changes a remote screenshot service.
4. Or skip the browser setup
ScreenshotNeo is a website screenshot API and MCP server. Its API takes a URL in one GET request and returns a screenshot image or PDF. Use a real target URL and your ScreenshotNeo API key:
See the ScreenshotNeo API documentation for request options and response details.
cURL
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com/hi/ -o shot.webp
Python
import requests
r = requests.get(
"https://api.screenshotneo.com/v1/shot",
params={"access_key": "YOUR_API_KEY", "url": "https://example.com/hi/"},
timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)
Node.js
const q = new URLSearchParams({
access_key: 'YOUR_API_KEY',
url: 'https://example.com/hi/'
});
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);
With Node.js versions that do not provide Bun.write, write the response bytes using Node’s filesystem API:
import { writeFile } from 'node:fs/promises';
const q = new URLSearchParams({
access_key: 'YOUR_API_KEY',
url: 'https://example.com/hi/'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await writeFile('shot.webp', Buffer.from(await res.arrayBuffer()));
ScreenshotNeo accepts cookie and consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Only clean shots are billed: bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, with X-Page-Verdict and X-Billed response headers indicating the result. Its MCP server gives AI agents tools named take_screenshot, get_page_info, and capture_pdf. The Free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000, and every feature is on every plan.
Sign up free for 1,000 screenshots a month, with no card required.
5. Troubleshooting Hindi text in screenshots
| Symptom | Likely cause | What to do |
|---|---|---|
| Hindi is missing in the screenshot and in the browser | Page content, localization, or application rendering issue. | Fix the page first. Check its locale selection, API/content response, and browser console before changing capture parameters. |
| Text appears as empty squares or boxes | The rendering font may lack the required Devanagari glyphs, or the intended font is unavailable. | Identify the page’s font family, confirm font files are accessible in the actual browser runtime, and check glyph coverage. For a managed runtime, inspect and install an appropriate font package. |
| Text is correct in a local browser but broken in a hosted capture | The local and hosted environments may have different fonts or timing. A local font installation does not configure a provider’s renderer. | Check what the hosted service documents about its renderer and font controls. ScreenshotMachine’s reviewed docs do not publish its font inventory or a font-upload/install option; do not assume a local package changes it. |
| Some letters are correct but others are boxes | Partial glyph coverage or fallback-font behavior. | Check the actual characters and font coverage rather than only the family name. Confirm the page’s declared web-font files finish loading. |
| Hindi appears after a manual refresh but not in the capture | Capture occurs before web fonts or page content are ready. | In a browser you control, await document.fonts.ready and any page-specific content condition. A documented fixed delay can provide time but does not verify font readiness. |
| Capture has the wrong language but valid text | The site may choose locale from a request header, cookie, URL, or application setting. | Try the documented accept-language header, then inspect how the site selects locale. Language selection and font selection are separate. |
| Image is stale after a font or page change | Service-side or page caching. | Review the API’s cache setting and confirm whether the returned result is fresh according to that provider’s documented cache semantics. |
| Output file exists but is not a readable image | The request may have returned an error body, invalid response, or unexpected format. | Use curl --fail, inspect the HTTP status and response headers, and verify the requested format and key against the official API documentation. |
6. Reliability, performance, and cost considerations
- Prefer readiness conditions to arbitrary sleeps when you own the browser. Waiting on
document.fonts.readymakes the font-loading condition explicit. You may still need to wait for application-specific content. - Keep the capture environment reproducible. Pin the container or operating-system image, font packages, browser version, and page assets when repeatable local results matter. Confirm that font files are present in the environment where the browser actually runs.
- Use a fixed delay as a bounded fallback. A delay can add latency to every request and still fail when fonts load later than expected. It cannot repair missing font files and is not equivalent to a font readiness check.
- Account for hosted-renderer uncertainty. The reviewed ScreenshotMachine material does not specify its font inventory or support for every Devanagari glyph. Treat output as something to inspect for your target page rather than relying on an undocumented font assumption.
- Control caching deliberately. Cached images can be useful when page output is unchanged, but a cached screenshot can hide whether a font fix worked. Follow the provider’s cache controls and verify with a fresh result when diagnosing.
- Do not infer a cost or performance benchmark from this guide. The available ScreenshotMachine research does not provide a relevant benchmark or verified pricing comparison. Check the service’s current pricing and request limits before planning batch capture.
7. FAQ
Does adding accept-language=hi install Hindi fonts?
No. It sets the request’s language preference as documented; font availability and glyph coverage are separate concerns.
Will increasing ScreenshotMachine’s delay always fix missing Hindi characters?
No. It may help if capture was early, but cannot add a missing font or guarantee a particular font loaded. The reviewed docs do not say the delay waits for font readiness.
Can I install a font on the computer running the ScreenshotMachine curl command?
The documented command calls a hosted API. The reviewed documentation does not establish that fonts installed on the client affect the remote renderer.
What is the strongest check when I control the browser?
Confirm glyph coverage in the runtime’s available fonts, then await document.fonts.ready and any page-specific content condition before capturing.


