How to Fix BrowserCat Screenshots Showing Broken Devanagari Text

If Devanagari text looks broken in a BrowserCat screenshot, first verify the page’s actual Unicode text, its language metadata, and its CSS font stack. Then inspect which font Chromium rendered and compare the same page in local Chromium and BrowserCat under matching capture conditions. BrowserCat documents cloud Chromium screenshot sessions and browser configuration, but its reviewed public documentation does not identify the installed fonts or document a way for customers to install one. If local Chromium renders correctly and BrowserCat does not, ask BrowserCat support whether its current backend has a suitable Devanagari font and whether a supported configuration can change it.

1. Confirm the text is valid Unicode

Before changing browser settings, determine whether the page itself contains the intended characters. A screenshot cannot repair text that was already corrupted before rendering.

Open the page in a browser and inspect the affected element’s text in developer tools.
Compare the DOM text with the intended content. Look for replacement characters such as �, unexpected Latin characters, or mojibake.
If the page is generated from a file, database, API, or template, inspect that source too. Confirm the content is decoded and served consistently as Unicode.

This is a general diagnostic step; the available sources do not identify a BrowserCat-specific encoding defect. If the DOM text is already wrong, fix the content pipeline before investigating fonts.

2. Check the page language and font stack

Make sure the document or the affected section declares the right language. Chrome’s font settings can depend on a page’s specified language, while CSS determines the requested font family and fallback sequence. Use a language tag appropriate to the content, such as hi for Hindi, or a more specific tag when it accurately describes the language and region.

<!doctype html>
<html lang="hi">
<head>
  <meta charset="utf-8">
  <style>
    body {
      font-family: "Noto Sans Devanagari", "Nirmala UI", sans-serif;
    }
  </style>
</head>
<body>
  <p>यह देवनागरी पाठ का उदाहरण है।</p>
</body>
</html>

The example declares a font preference; it does not install those fonts in BrowserCat’s remote runtime. A CSS family name only helps if a matching font is available to the browser. Check the page’s real stylesheet and computed styles as well as the document language.

3. Inspect the font Chromium actually rendered

A declared font-family is a preference, not proof that a particular font drew the glyphs. Chromium performs font fallback when choosing fonts for text runs, and its rendering documentation describes platform-specific text shaping and layout. In local browser developer tools, inspect the affected text’s rendered fonts if the tool exposes that information. Check the Devanagari run itself, including conjuncts, vowel signs, and marks, rather than relying only on the CSS declaration.

If the intended font is missing locally, install or load an appropriate font through a supported mechanism for that environment, then verify the result. For a remote BrowserCat session, do not assume that installing a font on your own computer changes the cloud browser.

4. Compare local Chromium with BrowserCat

BrowserCat’s documented Playwright workflow connects to a cloud browser session and captures the page through the browser’s screenshot API. Chromium’s platform fonts and fallback behavior can affect how a script renders, so compare equivalent captures before concluding what is responsible.

Capture the same URL locally and in BrowserCat.
Keep the viewport, device scale, browser family where available, page state, and wait condition as similar as possible.
Compare the DOM text, computed font stack, and rendered font for the affected text.
Record whether the local capture is correct, whether only BrowserCat is broken, and which characters or shaping marks differ.

A local-versus-remote difference points toward an environment difference, such as installed fonts or browser version; it does not by itself prove which one caused the problem. BrowserCat documents Chromium and Chrome choices, while Firefox and WebKit are described as coming later in the reviewed documentation. Do not assume that switching between Chrome and Chromium fixes the issue.

5. Ask BrowserCat about the remote font environment

BrowserCat’s public browser configuration documentation describes browser selection, CLI launch arguments, user preferences, and proxy options. The reviewed page does not document installed system fonts or customer font installation. That documentation gap does not prove there is no support-mediated option.

Send BrowserCat support a concise reproducible report containing:

The page URL or a minimal page that shows the problem.
The exact affected text and a screenshot of the result.
Whether the same page renders correctly in local Chromium.
The browser choice and version, if available, plus viewport and device scale.
The page’s lang value and relevant CSS font stack.

Ask whether the currently routed backend has Noto Sans Devanagari or another suitable Devanagari font, and whether BrowserCat supports any way to request or configure one. A Chromium source change dated March 4, 2026 adds Devanagari defaults for Linux and ChromeOS: standard and sans-serif map to Noto Sans Devanagari, serif maps to Noto Serif Devanagari, and fixed maps to Noto Sans Mono. This is version-specific evidence, and it does not establish which Chromium version BrowserCat deploys or which font files its backend has installed. See the Chromium source change and BrowserCat’s browser configuration documentation.

6. Retest the specific shaping details

After a page or runtime change, capture the same content again under the same conditions. Confirm that conjuncts, vowel signs, and reordering marks appear correctly and that the DOM text remains intact. Do not call the issue fixed until the resulting screenshot has been inspected.

Troubleshooting

Symptom	Likely area to inspect	Next step
The DOM contains incorrect characters	Content encoding, source data, or page generation	Fix the text before checking browser font fallback.
The DOM is correct, but both local and remote screenshots look wrong	Page language, CSS font stack, or fonts available in both environments	Check `lang`, computed styles, and the rendered font for the Devanagari run.
Local Chromium is correct but BrowserCat is broken	Remote runtime, installed fonts, or browser version	Send BrowserCat support a minimal reproduction and ask about its current font environment and supported configuration.
Changing `font-family` has no visible effect	The named font may not be installed or available to the browser	Inspect the actually rendered font; a CSS declaration does not install a font in a cloud session.
Only some marks or conjuncts look wrong	Font coverage or shaping of the specific text run	Retest representative combinations and compare which font rendered those characters.
A local Chrome font-setting change did not fix BrowserCat	The local and cloud browser environments are separate	Treat the local change as a local diagnostic only, and ask BrowserCat about its remote backend.

Performance, reliability, and cost considerations

For diagnosis, keep captures small and repeatable: use the same URL, viewport, scale, and wait behavior, and change one variable at a time. This makes differences easier to interpret and avoids spending time comparing captures of different page states. The research sources provide no BrowserCat benchmark, failure rate, or pricing figure relevant to this issue, so none is stated here.

Font availability is a runtime dependency. A correct local screenshot does not guarantee an identical remote rendering, and a browser update may change fallback behavior. Record the browser version and recapture after any runtime or page-font change. Chromium’s documented Linux and ChromeOS defaults are useful context, not confirmation of BrowserCat’s deployed setup.

Or skip the browser setup

If you need a screenshot API alternative to try first, ScreenshotNeo provides a one-request screenshot API and an MCP server for AI agents. It supports PNG, JPEG, WebP, or PDF output and offers custom CSS and JavaScript, wait conditions, viewport controls, and other capture options. For script-sensitive pages, verify the resulting image because the available ScreenshotNeo facts do not promise a particular Devanagari font in its capture runtime.

Install the Python dependency with python -m pip install requests, then run this complete example:

import requests

url = "https://example.com"
response = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": url},
    timeout=90,
)
response.raise_for_status()
with open("shot.webp", "wb") as image:
    image.write(response.content)

Equivalent one-call examples:

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

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

See the ScreenshotNeo API documentation for access keys and request options. Cookie banners are accepted like a visitor and 60+ known consent platforms, newsletter popups, and chat widgets are removed before the shot; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and responses identify the page verdict and billing status in headers. An MCP server provides take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients. The Free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 shots, and every feature is on every plan.

FAQ

Does setting `lang="hi"` guarantee correct Devanagari rendering?

No. It gives the browser language context, but the text, CSS, available fonts, and browser runtime still matter.

Does Chromium’s new Devanagari default mean BrowserCat has Noto fonts?

No. The cited change describes Chromium defaults for specific platforms. It does not identify BrowserCat’s deployed version or confirm its installed font files.

Can I fix a cloud screenshot by changing fonts in my desktop Chrome?

That only changes the local environment unless the remote service offers a supported way to configure its runtime.

Where can I find developer guidance for Devanagari support?

The W3C Internationalization resources cover developer and implementer work related to Devanagari and web technologies.