URL2PNG Screenshots Show Hindi Text Incorrectly: How to Fix Fonts
Fix incorrect Hindi text in URL2PNG screenshots by checking Devanagari font coverage, font loading, capture timing, and cached results.
If Hindi text looks wrong in a URL2PNG screenshot, first check the same page in a normal browser. Then verify that the page’s intended font loads successfully and includes Devanagari glyphs. If the page is correct in a browser but wrong in URL2PNG, try URL2PNG’s custom_css_url to select a Hindi-capable font already available to the page, test a short delay if the font loads late, and make sure you are viewing a fresh screenshot rather than a cached one. A delay cannot add missing glyphs or install fonts on URL2PNG’s renderer.
1. Find where the Hindi text breaks
Open the exact target URL in a current desktop browser and inspect the affected text. Note whether characters are missing, replaced by boxes, rendered in an unexpected typeface, or shaped incorrectly.
- Broken in the normal browser too: fix the site’s font declarations, font delivery, or fallback stack first.
- Correct in the browser, wrong in URL2PNG: investigate the capture’s CSS, timing, cache, and renderer differences.
Hindi text needs a font with Devanagari glyph coverage. A CSS rule that names a font does not guarantee that the browser successfully downloaded it, or that the font contains the required glyphs.
2. Check the site’s font coverage and delivery
- In the browser’s developer tools, inspect the affected text and its computed font family.
- Check the Network panel for the font-file request. Confirm it succeeds and is not blocked, missing, or returning an HTML error page.
- Verify that the selected font includes Devanagari glyphs. If it does not, choose a font that does and provide a suitable fallback.
- Reload the page and confirm the Hindi remains correct after fonts finish loading.
If the font request requires authentication, depends on a browser session, or is blocked by cross-origin or content-security rules, a screenshot renderer may not receive it in the same way as your browser. Make the required stylesheet and font assets reachable to the capture renderer, subject to the site’s security requirements.
3. Apply a Hindi-capable font with URL2PNG
URL2PNG documents custom_css_url for applying a stylesheet during capture. Put a rule selecting a Hindi-capable font in a stylesheet accessible to the renderer. For example, adapt this CSS to a font family and selector that your page can actually use:
/* capture-fonts.css */
body,
body * {
font-family: "Your Devanagari-Capable Font", sans-serif !important;
}Host that stylesheet at a URL the capture can fetch, then pass its URL using custom_css_url in your URL2PNG request. Follow URL2PNG’s current request format and authentication requirements in its Quickstart Guide; the documentation confirms the option but does not specify every cross-origin, authentication, or font-loading restriction. Make sure the selected family is available to the page, for example through a font stylesheet and font files the renderer can fetch. CSS can select a font; it cannot create missing glyphs.
URL2PNG advertises support for “Webfonts, Typekit,” but that capability statement is not a Hindi-specific guarantee. Its public documentation does not identify the renderer’s installed system fonts, browser version, shaping engine, or Devanagari-specific support. See URL2PNG’s product page.
4. Test capture timing and language settings
URL2PNG documents delay as a fixed wait after document readiness and asset loading. If the webfont loads late, test a small delay and compare the result. Increase it only enough to determine whether timing matters. A delay does not fix missing font coverage or a failed font request.
The accept_languages option overrides the HTTP Accept-Language header. Use it if the site serves different content or styles by request language. It is not a font selection or font installation option, and the documentation does not claim that setting a Hindi language header supplies Devanagari fonts.
5. Make sure the screenshot is fresh
URL2PNG documents a default screenshot TTL of 2,592,000 seconds (30 days) and a unique option to force a fresh screenshot by varying the request. When you change a stylesheet, font, or capture setting, use the documented fresh-capture mechanism so an older image does not hide the effect of your change. The ttl option controls the documented cache duration.
Viewport and full-page settings affect the captured dimensions, not font coverage. URL2PNG documents a default viewport of 1480×1037 and fullpage defaults to false. Adjust them only if text clipping or page layout is also part of the problem.
6. Troubleshoot by symptom
| Symptom | Likely cause | What to do |
|---|---|---|
| Hindi is broken in both browser and screenshot | The site’s chosen font lacks glyphs, its font request fails, or its CSS fallback is unsuitable. | Fix the site’s font stack and delivery; verify the font includes Devanagari. |
| Browser is correct, screenshot uses a different-looking font | The capture renderer did not use the same font or stylesheet. | Try custom_css_url with a reachable stylesheet and a Hindi-capable family available to the page. |
| Text is initially wrong but becomes correct after reload or waiting | The webfont may load after capture begins. | Check font request timing and test URL2PNG’s documented delay. |
| Changing CSS has no effect on the output | The stylesheet may not be reachable, the option may be malformed, or the image may be cached. | Confirm the stylesheet can be fetched, verify the request parameter, and force a fresh screenshot with unique. |
| The page changes language but the font remains wrong | accept_languages affects the request language header, not font coverage. |
Set the site’s font and CSS explicitly; use the language override only for language-dependent content. |
| The font works locally but not in URL2PNG | The renderer may not be able to fetch the font or may differ in its rendering environment. | Check asset accessibility and send a reproducible case to URL2PNG support. |
7. Escalate a reproducible URL2PNG-specific failure
If the page renders correctly in a normal browser but remains wrong in URL2PNG after checking font coverage, accessibility, timing, and cache, send support enough information to reproduce the issue:
- The exact public target URL and approximate capture time.
- A normal-browser screenshot showing the correct Hindi text and the URL2PNG output.
- The stylesheet used, relevant
custom_css_url,delay,accept_languages, and cache settings. - The font family and font-file request result, with any private tokens or sensitive data removed.
Ask whether the renderer supports the font and Devanagari shaping needed for the page. URL2PNG lists email support at support@url2png.com on its plans page. Its public documentation does not settle renderer-internal font availability or Hindi-specific guarantees.
8. Keep captures reliable and efficient
- Change one variable at a time: first confirm font coverage, then test CSS selection, then timing, then cache. This makes the result easier to diagnose.
- Keep delay targeted: extra waiting may help diagnose late fonts, but it increases time spent waiting and cannot fix a missing glyph.
- Control cache deliberately: force a fresh capture while debugging, then choose an appropriate TTL for routine captures.
- Check the full page only when needed: full-page capture can include below-the-fold content, but it does not repair typography.
- Save a small reproduction: a target page with a short Hindi sample and the exact font setup helps isolate service-specific behavior.
Or skip the browser setup
ScreenshotNeo is a website screenshot API and MCP server from ScreenshotNeo. It can accept cookie and consent banners before capture and remove 60+ known consent platforms, newsletter popups, and chat widgets; each step 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 gives Claude, Cursor, and other MCP clients screenshot tools. Plans include 1,000 screenshots a month free with no card; paid plans start at $5 for 3,000.
For Hindi font issues, the site still needs to load a font with Devanagari glyphs; a screenshot API cannot supply missing glyph coverage. If you want to capture the page without managing browser setup, make one request:
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpSee the ScreenshotNeo API documentation for request options. The same endpoint can be called from Python or Node.js:
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}`);Replace the example URL with your page. Create a free ScreenshotNeo account for 1,000 screenshots a month with no card.
Frequently asked questions
Can I fix missing Devanagari characters with a longer delay?
No. A delay can help if the correct font loads late. It cannot add glyphs to a font that does not contain them.
Does setting accept_languages to Hindi install a Hindi font?
No. It changes the HTTP language header and may affect language-dependent content, but it is not a font installation option.
Does URL2PNG guarantee Hindi rendering?
The reviewed public pages advertise webfont rendering but do not state a Hindi-specific guarantee. Ask support about renderer details if you have a reproducible case.
Should I switch screenshot providers to solve this?
First establish whether the page font loads and has Devanagari coverage. If the defect occurs only in a hosted renderer, share a reproduction with that provider; ScreenshotNeo is another API option to try, with clean captures and billing that excludes failed loads.
