Chrome Full-Page Screenshot Missing Devanagari Text: How to Fix It

If Devanagari text is missing from a Chrome full-page screenshot, first compare the screenshot with the live page. If the text is missing on the page too, inspect the rendered font and its Devanagari glyph coverage. If the page looks correct but the image does not, wait for page content and fonts to load, then capture with Chrome DevTools’ Capture a full size screenshot command. For automated captures, check that your method captures beyond the viewport: the DevTools Protocol’s captureBeyondViewport option defaults to false.

These checks narrow down likely causes; they do not identify a universal cause for every machine or page. The actual font, Chrome build, operating system, page behavior, and capture method all matter.

1. Check whether the live page is missing the text

Open the page normally in Chrome and find the affected Devanagari text.
Compare what you see on the page with the screenshot.
If the page itself has blank glyphs or missing text, investigate font selection and availability first.
If the page displays correctly but the screenshot does not, investigate capture timing, page length, and the capture tool’s settings.

This distinction matters: a screenshot records what the browser rendered at capture time. A capture setting cannot supply glyphs that the page failed to render, and installing a font is unlikely to explain an image that differs from a correctly rendered live page.

2. Inspect the font Chrome actually rendered

Use Chrome DevTools to inspect the affected text rather than relying only on the page’s CSS declaration. A CSS font stack can name several families, but the browser may use a fallback for characters the selected font does not support.

Right-click the affected text and choose Inspect.
With the text element selected, inspect its computed styles and the rendered-font information available in DevTools.
Check which font actually rendered the Devanagari characters, and whether that font has the required glyphs.
Compare the result across the affected machine and a machine where the page renders correctly, if one is available.

Chromium documents that missing glyph coverage can lead to blank rendering and that platform font fallback varies. A declared family alone does not prove that Chrome used a font with Devanagari coverage.

Test local versus web-hosted fonts

If the site uses @font-face with a local() source, Chrome DevTools’ Rendering panel provides Disable local fonts. Reload with that option enabled to compare the web-hosted font behavior with local font resolution. This is a diagnostic for pages using local font sources; it is not a general-purpose fix for every missing glyph.

If disabling local fonts changes the result, review the page’s @font-face sources and the actual files served. Confirm that the web font includes Devanagari glyphs and that it loads successfully. If it does not change the result, continue checking the rendered fallback, platform, and capture path.

3. Account for operating-system and Chrome differences

Font fallback can depend on both Chrome and the operating system. A Chromium source change committed on 2026-03-04 says Chromium previously had no configured default fonts for Devanagari and identifies platform mappings added in that change. The mappings are useful context, not a guarantee about every installed Chrome version, custom build, Linux distribution, or machine:

Platform	Mappings in the cited Chromium change
Windows	Nirmala UI for standard, serif, and sans-serif; Consolas for fixed-width.
macOS	Devanagari MT for standard and serif; ITF Devanagari for sans-serif; Menlo for fixed-width.
Linux	Noto Sans Devanagari for standard and sans-serif; Noto Serif Devanagari for serif; Noto Sans Mono for fixed-width.
ChromeOS	The same mappings as Linux in that change.

When results differ between machines, record the operating system and Chrome version and check whether the listed or site-provided fonts are actually available and selected. The Chromium mapping change does not establish that a particular machine has those fonts installed or that an older Chrome release uses those defaults. See the Chromium source change.

4. Capture the whole page with Chrome DevTools

Chrome DevTools distinguishes a viewport screenshot from a full-size screenshot. To capture the whole page manually:

Open DevTools on the page.
Open the device toolbar, then its More options menu.
Choose Capture a full size screenshot, not Capture screenshot, which captures the current viewport.
Let the page settle first if it loads content or fonts dynamically, then inspect the resulting image.

See Chrome’s device mode documentation for the full-size screenshot workflow. If the live page is correct but the full-size result still omits text, compare it with a viewport capture and continue with the automated-capture checks below where applicable.

5. Check headless and protocol-driven captures

Do not assume every screenshot command captures the entire document. Chrome’s headless documentation describes the --screenshot command and notes that full-page capture involves additional steps. The basic command alone should not be treated as proof that an arbitrarily long page was captured. See the headless Chrome documentation.

If your automation uses the Chrome DevTools Protocol, inspect the Page.captureScreenshot options and the viewport state. The protocol documents captureBeyondViewport as defaulting to false. Check whether your capture explicitly includes content beyond the viewport and whether the clip or viewport dimensions exclude the affected section. See the Page.captureScreenshot protocol reference.

For any automated method, also wait until the page’s content and fonts have loaded before taking the image. The cited documentation supports checking capture controls; it does not prove that a font-loading race caused a particular screenshot failure.

6. A practical diagnosis checklist

Text absent on the live page: inspect the actual rendered font, glyph coverage, font loading, operating system, and Chrome version.
Text present on the page but absent in the screenshot: retry after loading settles; compare viewport and full-page capture; check automation timing and capture settings.
Only content below the fold is missing: confirm that the capture includes beyond-viewport content and that no clip limits the image.
Only one machine is affected: compare its available fonts and Chrome build with a machine where rendering works.
Page uses local() font sources: use DevTools’ Disable local fonts setting as a controlled diagnostic, then check the web-hosted font path.

Or skip the browser setup

ScreenshotNeo provides a one-request website screenshot API. For API details and options, see the ScreenshotNeo documentation.

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,
)
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}`);

ScreenshotNeo accepts cookie and consent banners and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each of those steps can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers report the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for AI agents and MCP clients. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots. Every feature is on every plan. ScreenshotNeo is a website screenshot API and MCP server for developers, made by Yorker Media; learn more at ScreenshotNeo.

Performance, reliability, and cost considerations

For your own browser capture, waiting for fonts and dynamic content improves the chance that the screenshot reflects the page’s settled rendering, but the right wait condition depends on the page. A fixed delay can be wasteful on fast pages and insufficient on slow ones; where your automation supports it, wait for the relevant content or font readiness and verify the output. Full-page images can also be large, so consider the required dimensions and output format when storing or transferring captures.

For protocol-driven capture, verify the page dimensions, capture-beyond-viewport behavior, and any clip settings on every run. A successful screenshot command does not itself establish that the intended lower-page content was included. For ScreenshotNeo, only clean shots are billed; its responses expose page-verdict and billing headers, which let you distinguish billed captures from non-billed outcomes. Its published plans range from 1,000 free monthly shots to paid tiers, with yearly billing giving two months free.

Troubleshooting common symptoms

Symptom	Likely area to check	Next step
Devanagari is blank in both page and image	Font availability, fallback, or glyph coverage	Inspect the rendered font in DevTools and compare the platform and Chrome build.
Page is correct; screenshot has missing text	Capture timing or method	Wait for content and fonts to load, then use DevTools’ full-size screenshot and compare outputs.
Only lower-page text is absent	Viewport-only or clipped capture	Check that the method captures beyond the viewport; protocol capture defaults that option to false.
Local font setting changes the rendering	`@font-face` with `local()`	Check the local font and web-hosted font separately, including the latter’s glyph coverage and load result.
Different machines produce different text	Platform font fallback or Chrome version	Compare actual rendered fonts, installed fonts, operating systems, and Chrome versions.
Headless output is shorter than the page	Basic screenshot command or capture bounds	Use a documented full-page workflow or set and verify the protocol’s viewport and beyond-viewport options.

These are diagnostic directions, not a claim that one cause applies to every case. The evidence reviewed does not include the affected page or machine. To narrow down a specific failure, collect the page URL, operating system, Chrome version, whether the live page displays the text, and the capture method.

FAQ

Does a full-page screenshot fix missing Devanagari fonts?

No. Full-page capture controls what page area is included. If the live page itself lacks the glyphs, investigate font rendering and availability.

Does the Chromium font mapping apply to every Chrome version?

No. The cited mappings come from a particular Chromium source change. Installed fonts, Chrome versions, custom builds, and platform behavior can differ.

Can I assume `--screenshot` captures the entire page?

No. Chrome’s headless documentation describes full-page capture as requiring additional steps beyond the basic screenshot command.

What details help diagnose a specific screenshot?

Provide the page URL, operating system, Chrome version, whether the live page shows the Devanagari text, and the tool or method used to capture it.