How to fix PageCrawl.io screenshots that do not load Indian-language fonts

If Indian-language text appears as boxes, blank spaces, or a different typeface in a PageCrawl.io screenshot, check three things first: whether the screenshot browser can fetch the font, whether that font contains the affected script and characters, and whether capture waits for the used fonts to load. A CSS family name by itself does not load a font. PageCrawl documents custom JavaScript actions for some workflows, but its reviewed help pages do not document a dedicated Indian-language font setting or guarantee that every screenshot mode exposes a font-readiness action.

The diagnosis is the same whether the text is in Devanagari, Bengali, Tamil, Telugu, or another script. Compare the same text in a normal browser and in the capture, then check the font request, CSS face declaration, glyph coverage, and timing in that order.

1. Compare the page and the screenshot

Open the source page in a regular browser and inspect the exact affected text.
Compare it with the PageCrawl screenshot for the same URL and content.
If both render incorrectly, start with the site’s font files and CSS. If only the screenshot does, investigate what the capture browser can access, its request permissions, and when that capture occurs.

This comparison narrows the investigation; it does not establish which operating system fonts PageCrawl’s browser has installed. Do not assume that a particular system font is present in its capture environment.

2. Check whether the screenshot browser can fetch the font

In the browser where you can reproduce the problem, open Developer Tools and inspect the Network and Console panels while loading the page. Filter requests to font resources, such as WOFF or WOFF2 files. Check that the stylesheet and font request succeed, the URL is correct, and the response is not blocked by authentication, a network failure, or cross-origin access controls.

When a font is hosted on a different origin, its server may need to permit cross-origin use. A font URL that works in your logged-in browser may still fail in a capture environment that lacks the same access or session. See MDN’s documentation on @font-face and cross-origin resource sharing.

What to record

The font request URL and its HTTP status.
Any Console message about a blocked font, failed request, or invalid font.
Whether the font is served from the page’s origin or another domain.
Whether the font URL requires a cookie, authorization, or another form of access.

3. Verify the face declaration and script coverage

Confirm that the CSS applied to the affected text names the same family as the declared font face, and that the declared face matches the weight and style the text requests. A regular face does not necessarily provide a bold face; the browser may synthesize a weight or select a fallback.

@font-face {
  font-family: "SiteText";
  src: url("/fonts/site-text.woff2") format("woff2");
  font-style: normal;
  font-weight: 400;
  font-display: swap;
}

.article-copy {
  font-family: "SiteText", sans-serif;
  font-weight: 400;
}

This is a general example, not a PageCrawl-specific setting. Adapt the family, URL, formats, and weight declarations to the font you actually serve. Check that the font file contains the glyphs for the affected language and the exact characters in the page. If you use unicode-range, verify that it covers those code points. The range determines which characters a font resource applies to; it does not prove that the font file contains every glyph in that range. See MDN’s unicode-range documentation.

You can inspect the declaration and loaded faces in Developer Tools. A successful font request alone does not mean that the file has the glyphs the page needs. Likewise, document.fonts.load() is not a complete glyph-coverage test: its optional text argument filters faces by Unicode-range match, but does not check individual glyph coverage. See MDN’s FontFaceSet.load() reference.

4. Wait for used fonts before capture

A page can capture before a font has finished loading, especially when content or styles change after navigation. In a browser workflow that allows a custom JavaScript action, wait for the fonts currently used in the document after the page content and styles are ready:

await document.fonts.ready;

For example, if the action runner expects an async function expression:

(async () => {
  await document.fonts.ready;
})();

MDN describes this promise as fulfilling when loading and layout operations for all used fonts are done. It does not promise that every declared but unused or optional face has loaded. If an action changes text, classes, or styles after the first wait, wait again after that change.

PageCrawl documents custom JavaScript actions that run before tracked-element extraction, support asynchronous waits, and have a 30-second safety timeout. Its documentation does not establish that every screenshot workflow exposes this action or that the action guarantees font readiness for screenshots. Confirm that the affected monitor or capture mode supports the action, then inspect the resulting screenshot. See the PageCrawl custom JavaScript actions documentation and MDN’s Document.fonts reference.

5. Fix the site’s font setup if you control it

Make the font file reachable without credentials the capture browser does not have.
For fonts hosted on another origin, configure the font server to permit the page’s origin.
Check that the file includes the needed script and characters, and that any unicode-range includes the page’s actual code points.
Declare the weights and styles the content uses, and apply the correct family to the affected text.
Wait for used fonts after navigation and after any later change to text or styles.
Retest with the same language sample, URL, and PageCrawl capture mode.

PageCrawl’s troubleshooting help covers general page-loading and language-change issues. The reviewed help pages do not provide a dedicated Indian-language font setting. If the problem persists only in PageCrawl, send its support team the page URL, exact affected script and sample text, font family and weight, whether a regular browser renders it correctly, relevant failed font requests or Console errors, and the monitor or check context.

Or skip the browser setup

If your goal is to get a screenshot through an API rather than diagnose a PageCrawl capture, ScreenshotNeo is a website screenshot API and MCP server. It returns a PNG, JPEG, WebP, or PDF from one GET request. Its clean-shot behavior accepts cookie and consent banners like a visitor, then removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each cleanup step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers report the page verdict and billing status.

Use this cURL example to save a WebP screenshot of a page you can access:

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

See the ScreenshotNeo API documentation for authentication and options. The same API also works with common screenshot parameter names, which can simplify switching. An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients. One thousand screenshots a month are free with no card; paid plans start at $5 for 3,000. Sign up for free and get 1,000 screenshots a month with no card.

Troubleshooting checklist

Symptom	Likely cause	What to check or change
Boxes or missing glyphs in both the normal browser and capture	The font lacks the glyphs, or the page does not apply the intended face.	Check the font file’s script coverage, the applied family, and the declared weight and style.
Correct in a normal browser, fallback in the capture	The capture cannot retrieve the font, or capture happens before it loads.	Inspect request access, authentication, cross-origin errors, and capture timing.
Font request fails or is blocked	Bad URL, inaccessible resource, or cross-origin policy.	Correct the URL or access configuration and allow cross-origin font use where needed.
Some characters render while others do not	Subset or glyph coverage gap, or a restrictive `unicode-range`.	Check the exact code points and font file coverage; adjust the subset or range.
Text switches from fallback after the screenshot	Capture was taken before the used font and layout settled.	Wait for `document.fonts.ready` after content and style changes, if the capture mode supports an action.
Wait action times out	Font or page work exceeded the action runner’s limit, or a font request is stalled.	Inspect failed or slow requests first. PageCrawl documents a 30-second safety timeout for JavaScript actions; do not assume the timeout can be extended.

Performance, reliability, and cost considerations

Font loading adds work to the critical path. A readiness wait can improve capture fidelity, but a stalled font request can delay capture. Find and fix the request issue rather than adding an arbitrary long sleep.
Wait for the right event. document.fonts.ready tracks used fonts and layout, while a fixed delay only waits for time to pass. Recheck after changes that cause new text or styles to use a face.
Test the exact sample. A page heading may use different characters, weights, or styles from the body text. Validate representative text from the affected script.
Use the same capture path for retests. A successful regular-browser render does not prove that a separate capture environment can access the same font resources.
Do not infer PageCrawl billing or guarantees. The reviewed sources do not establish a font-specific setting, capture guarantee, benchmark, or cost for this problem. Check the current PageCrawl account and plan documentation for commercial details.

Frequently asked questions

Does this only affect Hindi?

No. The same checks apply to any script: font access, face selection, glyph coverage, and capture timing. Use the exact characters that fail as your test sample.

Does a successful font load prove the script will render?

No. A request can succeed while the font lacks particular glyphs. Check the font’s actual coverage and the text’s code points.

Does PageCrawl have a dedicated Indian-language font option?

The reviewed PageCrawl help pages do not document one. They document general troubleshooting and custom JavaScript actions for supported workflows.

Will waiting for `document.fonts.ready` load every font declared in the CSS?

No. It resolves for used fonts after their loading and layout operations settle; unused or optional faces may not load.