How to capture an Indian-language webpage correctly with Chromium

To capture an Indian-language webpage correctly with Chromium, first confirm that Chromium has rendered the intended script with a font that contains its glyphs, then wait for fonts and page content to be ready before capturing. A screenshot records rendered pixels, so correct HTML alone does not guarantee readable output. For a normal viewport image, use Headless Chromium’s --screenshot and set the viewport with --window-size. For a complete long page, use an explicit full-page capture workflow: the documented command-line screenshot option does not promise a full-page image.

Font rendering can vary by platform, so record the browser version, operating system, viewport, and font environment when you need repeatable output. The Chromium project describes font rendering as platform dependent in its overview of how Chromium displays web pages.

1. Check the page’s script and actual font

Before capturing, open the actual rendered page in Chromium. Do not rely on raw HTML or a DOM dump to tell you what the screenshot will look like. A DOM dump reflects parsed and script-executed markup, not the rendered pixels.

Check that the page declares the correct language where possible, for example with an appropriate lang attribute. Language can affect script-sensitive font selection.
Use DevTools to inspect representative text and identify the font Chromium actually rendered. A CSS font-family declaration is a preference list; if a font is missing or lacks the required characters, the browser can fall through to another face. See Chrome’s guide to identifying the rendered font and the font settings and language behavior.
Check more than one line and include representative characters, conjuncts, and diacritics for the script in question. Look for missing-glyph boxes, unexpected fallback styles, clipped marks, overlaps, and changed line breaks.
If the site uses a web font, confirm that its font request succeeded and that the font finished loading before capture.

Web fonts may be temporarily invisible or shown in a fallback face while they load. Chrome’s guidance on keeping text visible during web-font loading explains the font-display choices swap, optional, and fallback. A screenshot taken too early may therefore look different from the intended page.

2. Capture a Chromium viewport screenshot

Install Chromium or Chrome in the environment where the capture will run, then use its Headless command-line interface. The following captures the visible viewport at 1280 × 900 pixels:

chromium --headless --screenshot --window-size=1280,900 "https://example.com/page"

Depending on the operating system and installation, the executable may be named chromium, chromium-browser, or google-chrome. Replace the URL and binary name with the ones for your environment. Chromium writes a screenshot file in its working directory by default. Add --timeout to bound how long Headless waits, for example:

chromium --headless --screenshot --window-size=1280,900 --timeout=10000 "https://example.com/page"

The timeout is a maximum wait, not proof that a particular page’s fonts, images, or dynamic content are ready. Consult the official Chrome Headless command-line reference and check the flags supported by your installed build.

Choosing viewport dimensions

--window-size=WIDTH,HEIGHT controls the capture viewport. Set dimensions to match the intended display or review target. A taller viewport can reveal more content at once, but it does not mean Chromium will capture the entire document. If the page is responsive, changing width can also change its layout and line wrapping, so use the actual target width when visual fidelity matters.

3. Wait for fonts and dynamic content

For a static page, a suitable timeout may be enough. For pages that load fonts, images, or text asynchronously, use a browser automation workflow that waits for page-specific readiness conditions before taking the screenshot. When you control the page, wait for its font-loading state and for the content you need to appear. Also account for content that loads only after scrolling.

Do not assume that a fixed delay guarantees readiness: network speed and page behavior vary. Prefer an explicit condition, such as a required element becoming visible and fonts finishing their load, with a maximum timeout so a stalled page does not wait forever. This is workflow guidance; the Headless command-line timeout itself does not verify those conditions.

4. Capture a full page or save a PDF

The basic Headless --screenshot example is viewport-oriented. The reviewed official command-line reference documents no dedicated full-page screenshot flag, so do not treat a large --window-size as a guarantee that a long document will fit in one image. To capture the whole page, use an automation or capture workflow that explicitly supports full-page screenshots. Then inspect the result for lazy-loaded sections, fixed or sticky elements, and clipping. If useful, capture sections deliberately rather than producing an unwieldy single image.

For a printable document, Headless Chromium can produce a PDF:

chromium --headless --print-to-pdf="page.pdf" "https://example.com/page"

A PDF is a different deliverable from a single full-page image: it can span pages and is often more suitable for printing or sharing as a document. Review page breaks, font appearance, and whether the result meets your need for selectable text. The official command-line reference documents --print-to-pdf as PDF output; it does not promise a specific page layout for every site.

5. Inspect the screenshot before using it

Confirm the intended script is legible at the final output dimensions.
Check representative glyphs, conjuncts, and diacritics for missing characters or clipping.
Look for fallback fonts that change the page’s line breaks or visual hierarchy.
Confirm content that loads after scrolling is present if you need a full-page result.
Repeat captures in the same browser, operating system, viewport, and font environment when you need consistent comparisons.

If output differs across machines, compare the operating system, installed fonts, Chromium build, and actual font resources. Platform-dependent font rendering can change appearance even when the page URL and CSS are the same.

Common problems and fixes

Symptom	Likely cause	What to do
Boxes or blank spaces appear instead of characters	The selected font does not contain the needed glyphs, or its font file failed to load.	Inspect the rendered font in DevTools, check the font request, and ensure the page has a usable fallback with script coverage. Wait for font loading and capture again.
The first capture uses a different-looking font	The screenshot was taken before the web font loaded, or Chromium used a fallback.	Wait for the page’s font-loading state and required content, then recapture. Review the site’s `font-display` behavior.
Text differs between two computers	Font availability, operating system, browser build, or platform-specific rendering differs.	Record and align the environment where possible; check which font actually rendered on each machine.
The bottom of the page is missing	The screenshot captured only the viewport.	Use a workflow with explicit full-page support or capture sections; inspect lazy-loaded content after scrolling.
A timeout occurs or content is incomplete	The page or its resources did not become ready within the wait, or the fixed timeout expired.	Check network and console errors, allow an appropriate maximum wait, and use a page-specific readiness condition. A longer timeout alone cannot guarantee readiness.
Line breaks or marks look clipped	The viewport differs from the target, the fallback font has different metrics, or the output is reviewed at an unsuitable scale.	Capture at the intended width and inspect the image at its actual delivery size; confirm the intended font rendered.

Performance, reliability, and cost considerations

Headless Chromium avoids the need to capture from a visible desktop window, but it still has to load the page and its required resources. Waiting for fonts and page-specific content improves reliability; unbounded waits can leave a job stuck, while arbitrary short delays can produce incomplete output. Use a maximum timeout together with readiness checks where your automation allows them.

For repeatable results, pin or record the Chromium version, operating system, viewport dimensions, and font environment. A locally installed font and a downloaded web font can produce different results if one is unavailable or loads late. The dossier’s official references provide no general benchmark or cost figure for this workflow, so runtime and infrastructure cost depend on the page and environment.

Or skip the browser setup

ScreenshotNeo is a website screenshot API. Its one-request endpoint returns a PNG, JPEG, WebP, or PDF and handles the browser capture setup for you. See the API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com/page -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"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://example.com/page'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const image = Buffer.from(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', image));

Cookie and consent banners are accepted and removed before capture, along with known newsletter popups and chat widgets; each cleanup step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers report the page verdict and billing status. ScreenshotNeo also has an MCP server for AI agents, including 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 screenshots.

FAQ

Does `--dump-dom` show what the screenshot will look like?

No. It outputs a serialized DOM after parsing and script execution; it does not show the rendered pixels or prove that fonts appeared correctly.

Will Chromium use the font named in the page’s CSS?

Only if that face is available and suitable for the characters. Otherwise, font selection can fall through to another family.

Does a PDF guarantee that every font will look the same on every system?

The reviewed command-line documentation establishes PDF output, not identical rendering across systems. Check the generated document in the environment where it will be used.