How to Capture Hindi Website Pages in Percy Without Font Mismatches
Make Percy render Hindi text with the intended font: verify glyph coverage and font delivery, wait for fonts to load, and diagnose asset discovery.
To capture Hindi pages in Percy without font mismatches, ensure the Hindi text uses a reachable font that includes its Devanagari glyphs, then wait for the page’s used fonts to load before taking the snapshot. If the test browser looks correct but Percy does not, investigate whether Percy can discover and access the font and CSS assets.
A practical browser-side synchronization step is await document.fonts.ready immediately before the Percy snapshot. It waits for used fonts and associated layout work; it is more reliable than an arbitrary sleep. It does not guarantee that every declared but unused font has loaded, or that content inserted afterward is ready.
1. Check the Hindi text’s font and glyph coverage
Start with a representative Hindi text node in the page’s final visual state. In browser developer tools, inspect its computed font-family and confirm the intended face wins font matching. Then inspect the corresponding @font-face rule and its src URL.
- Confirm the Hindi text is actually styled with the expected family and weight.
- Check whether the font declares a
unicode-range. A subset may cover only some characters, leaving other Devanagari glyphs to a fallback face. - In the Network panel, confirm the font request succeeds from the automated test environment. Check for blocked requests, incorrect URLs, authentication requirements, CDN failures, or cross-origin restrictions.
- Compare the code points in any mismatched characters with the font subset’s coverage. Partial coverage can make only some characters appear different.
CSS @font-face can use local or remote font sources, and its src descriptor lists candidates the browser can try. WOFF2 is generally recommended for web delivery, but changing formats will not fix an inaccessible URL or missing glyph coverage. See MDN’s guides to @font-face and the src descriptor.
2. Wait for fonts before taking the Percy snapshot
With a browser automation setup that exposes a page evaluate method, await the document’s font readiness after navigation and after the Hindi content is present and styled:
await page.evaluate(() => document.fonts.ready);
await percySnapshot(page, "Hindi page");
This is the essential ordering: the final page state first, font readiness second, snapshot third. Adapt the page handle and snapshot call to your framework’s Percy integration. The Percy snapshot API is supplied by the SDK you use; this example shows the synchronization point rather than a framework-specific setup.
When the page changes after the first wait
If client-side navigation, hydration, or a later content update inserts Hindi text or applies new styles, wait again after that change. The set of fonts used by a document depends on the text and styles present when the browser evaluates it. document.fonts.ready resolves for the document’s used fonts and related layout work; it is not a promise that all font faces declared in CSS, including unused faces, have loaded.
MDN documents this behavior in the CSS Font Loading API. Waiting for this condition avoids guessing at a timeout that may be too short on a slow run or unnecessarily long on a fast one.
3. If Percy still differs, check asset discovery
Percy’s process includes capturing the page, discovering assets, and rendering the snapshot for comparison. A font visible in the local test browser is not by itself proof that Percy’s discovery and rendering stages can access the same asset.
- Compare the local automated-browser rendering with Percy’s rendered snapshot, using the same viewport and application state.
- Review Percy’s self-debugging or asset-discovery diagnostics for failed font and CSS requests.
- Check that the font host is accessible to Percy’s asset discovery and is not excluded by host restrictions or blocked by access controls.
- Confirm the font URL and CSS response are valid from the capture environment, not only from a developer’s browser session.
- After making the final page changes, rerun the capture and inspect the baseline, current render, and diff.
BrowserStack’s Percy troubleshooting documentation covers self-debugging and assets such as fonts and CSS that may fail to load. Its Percy capture guidance describes a default network-idle discovery interval of 100 ms without new requests. That interval is an asset-discovery behavior, not a replacement for ensuring your application has reached the intended state. Check the documentation for your installed SDK and configuration for version-specific controls.
The reviewed Percy material describes the general capture workflow; it does not guarantee automatic selection or embedding of a particular Hindi font. Verify the actual font and Hindi text used on your page.
4. Troubleshooting common Hindi font mismatches
| Symptom | Likely cause | What to check or fix |
|---|---|---|
| Hindi text is wrong in the test browser and Percy | The intended face did not load, does not cover the characters, or is not applied to the text. | Inspect computed font-family, the @font-face rule, font request status, and subset coverage. Correct the declaration or asset delivery. |
| The test browser looks right, but Percy differs | Percy cannot discover or access the font or CSS asset. | Inspect Percy diagnostics and host access. Confirm the font asset is available to the capture and rendering workflow. |
| The result varies from run to run | The snapshot races with font loading, layout, or a late page update. | Wait for the final content and styles, then await document.fonts.ready immediately before capture. Wait again after updates. |
| Only some Hindi characters differ | A subset or unicode-range excludes some code points, or another face wins matching for those glyphs. |
Check the actual characters against the font coverage and inspect which face is applied to the affected text. |
| The font request fails in automation | The URL is wrong or the host, authentication, cross-origin policy, or CDN prevents access. | Inspect the request and response in the automated browser’s Network panel; make the asset reachable under the capture environment’s access rules. |
| Waiting for fonts did not change the capture | The used font itself is unavailable or incorrect, the Hindi content was inserted after the wait, or Percy’s asset stage has a separate access issue. | Verify font selection and coverage first, repeat the wait after final content updates, then inspect Percy asset discovery. |
5. Keep captures reliable and efficient
- Synchronize on state: wait for navigation and application updates, then fonts. Avoid fixed delays as the only readiness check.
- Use consistent capture conditions: keep viewport and page state stable when comparing runs so unrelated layout changes do not obscure the font issue.
- Keep font assets reachable: avoid relying on a font that is available only in a developer’s local environment when the capture runs elsewhere.
- Diagnose stages separately: first establish that the automated browser renders the intended face; then investigate Percy’s asset discovery if its output differs.
- Account for the content actually used: an unused font face need not be loaded by
document.fonts.ready. Make sure the Hindi text is in the document before waiting.
No benchmark or cost figure is needed to diagnose this rendering problem. The practical reliability improvement is to wait on the browser’s font readiness condition and verify access at both the test-browser and Percy stages.
Or skip the browser setup
ScreenshotNeo is a website screenshot API and MCP server for developers. For an independent screenshot of a Hindi page, make one request to the API. See the ScreenshotNeo API documentation for configuration options.
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}`);
Replace the example URL with your Hindi page. ScreenshotNeo removes cookie banners, popups, and chat widgets before capture; bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000.
Sign up for 1,000 free screenshots a month, no card required.
FAQ
Does document.fonts.ready load every font declared on the page?
No. It resolves after fonts used by the current document and related layout work are complete. Ensure the Hindi content is present and styled before awaiting it.
Will switching to WOFF2 fix every mismatch?
No. WOFF2 is generally recommended for web delivery, but a font still needs to be reachable, correctly declared, and cover the Hindi characters in use.
Does a correct local screenshot guarantee Percy will match?
No. Percy’s asset discovery and rendering stages must also be able to access the relevant font and CSS assets.


