How to capture an Indian-language website with Loki without broken fonts

To capture an Indian-language website with Loki without broken fonts, render the real script in a Storybook story, load the same font configuration as the site, and make asynchronous content ready before capture. Loki captures Storybook stories; it is not a general-purpose crawler that automatically screenshots arbitrary production URLs. Create a reference, inspect the actual glyphs in the image, then compare future captures and approve a new reference only after confirming it is correct.

1. Understand what Loki captures

Loki is a visual regression testing tool for Storybook projects. Its documented workflow uses a running Storybook server or static Storybook input, captures stories in a configured browser or device target, and compares images against references. It does not provide an Indian-script font repair feature. The font checks in this guide are practical steps around the rendered story, not Loki-specific font settings. See the Loki documentation.

2. Prepare a representative Storybook story

1. Choose a component that actually displays the language and script you need to protect.
2. Put representative real words and punctuation in the story. Latin placeholder text cannot reveal missing Indic glyphs, fallback fonts, shaping problems, or line-wrap changes.
3. Use the same CSS, font-family, font-weight, and font-loading configuration as the corresponding site component.
4. Ensure the relevant font files are available to the Storybook environment. Check the browser’s network and console output for failed font requests.
5. Include enough surrounding layout to reveal changed line height, wrapping, clipping, or component shifts.

Do not assume that a successful Loki command means the intended font rendered. The screenshot is the evidence to inspect.

3. Make content and fonts ready before capture

Asynchronous data, language selection, and animation can make captures unstable. Loki documents an async-story callback pattern for stories that need preparation before capture. Use it when the story fetches data or performs asynchronous setup, and signal completion only after the language-dependent content is rendered and any required requests have succeeded. Consult Loki’s current documentation for the async-story pattern supported by your version.

For web fonts, verify readiness in the browser rather than treating a longer page-load timeout as a font guarantee. Loki’s --chromeLoadTimeout controls how long it waits for page load; the reviewed documentation does not say that it waits for document.fonts.ready. If needed, make font readiness explicit in the story’s setup and confirm the font actually loaded in the browser.

4. Choose a stable browser or device target

Use a Loki target that matches the environment you want to protect, such as Chrome for a web component or a mobile simulator/emulator for a mobile target. Keep the target consistent when creating and comparing references. Browser version, operating system, installed fonts, device rendering, and available font files can change pixels even when application code has not changed. Loki documents Chrome and mobile targets; consult its target configuration for the exact options available in your installed version.

5. Create a baseline, test, and inspect

1. Start or build the Storybook input Loki will capture, following your project’s existing configuration.
2. Run yarn loki update to create the initial reference images.
3. Open the captured image. Confirm the Indian-language glyphs, marks, spacing, line breaks, and surrounding layout are correct.
4. After a code or dependency change, run yarn loki test.
5. Inspect both the current screenshot and the visual difference. A diff shows changed pixels; it does not identify whether the cause was a missing font, failed request, fallback, content timing, or environment change.
6. Approve or update a reference only after verifying that the current capture is correct. Loki documents yarn loki approve as an approval route; follow the command suggested by your installed version.

Loki writes current screenshots and difference images to configured output locations. Keep reference images and the browser target strategy consistent across the team so comparisons remain reproducible.

6. Useful configuration points

Setting or choice	When it helps	What to check
--chromeLoadTimeout	The page needs more time to load.	This is a general page-load wait, not documented as a web-font readiness guarantee.
chromeSelector	You want to capture a specific region.	Include the text and enough surrounding context to detect layout changes.
Diff engine	You need to configure how image differences are evaluated.	Use the settings documented for your Loki version and inspect images visually for font issues.
Reference, output, and difference locations	You need repeatable artifacts in local or CI runs.	Keep paths and reference storage consistent and accessible to the team.
Browser/device target	You need to protect a particular rendering environment.	Use the same target for baseline and later runs, and make sure required fonts exist there.

These options control capture and comparison. They do not select an Indian-language font or diagnose script coverage for you. Check your font’s language coverage, CSS family and weight declarations, and browser font requests separately.

7. Troubleshooting

Symptom	Likely cause	What to do
Glyphs appear as boxes, blanks, or replacement characters	The chosen font lacks glyph coverage, a font file failed to load, or the browser fell back unexpectedly.	Inspect the screenshot, browser console, and network requests. Verify font files, CSS family/weight, and script coverage.
Text looks correct locally but broken in CI	The browser or operating-system environment differs, or the font asset is unavailable there.	Use a stable Loki target and ensure the same font assets and configuration are available in CI.
Captures alternate between correct and incorrect	Font or content loading is asynchronous, requests are unreliable, or animation changes the image.	Make story preparation deterministic, use Loki’s async-story support where appropriate, confirm requests succeed, and stabilize animation.
The command succeeds but the baseline is wrong	Command success only indicates the capture workflow ran; it does not establish that glyphs rendered correctly.	Do not approve the image. Fix the rendering problem, capture again, and review the result.
The diff is large after an environment change	Browser, platform, device, or font availability changed.	Restore the prior target for a like-for-like comparison, or deliberately review and establish a new verified baseline.
The relevant text is missing from the screenshot	The wrong story or capture region was selected, or content had not rendered.	Confirm the story contains the target text, adjust the capture selection such as chromeSelector, and ensure async rendering completes.

8. Performance, reliability, and cost

Loki’s capture time depends on the stories, browser/device target, and work the story performs. Reducing unnecessary network dependencies and making stories deterministic helps avoid flaky captures. A longer load timeout can accommodate slow pages, but does not establish that fonts are ready or correct.

For reliable visual regression, keep the target, story data, font assets, and reference storage consistent. Treat a diff as a signal to investigate, not as a diagnosis. There are no topic-specific published benchmark figures in the cited Loki material, so capture speed and stability should be evaluated in your own project environment.

Loki is a development dependency and workflow; this guide does not assume a separate physical product purchase. ScreenshotNeo’s separate hosted API has its own published plans, described below.

Or skip the browser setup

If you need a screenshot of a live page rather than a Storybook regression test, ScreenshotNeo is a website screenshot API and MCP server. Its API returns an image or PDF from one GET request. See the ScreenshotNeo API 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 removes cookie banners, popups, and chat widgets before the shot. 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. Create a free ScreenshotNeo account.

FAQ

Can Loki screenshot any production URL?

No. The workflow described here captures Storybook stories from a Storybook server or static Storybook input.

Does increasing --chromeLoadTimeout fix missing glyphs?

It can allow more time for page loading, but Loki’s reviewed documentation does not describe it as a web-font readiness check or font repair.

Should I approve a reference when the diff is expected?

Only after checking the new screenshot itself and confirming the script renders correctly. An expected code change can still produce an unintended font fallback.

Can ScreenshotNeo replace Loki visual regression tests?

They serve different workflows: Loki compares Storybook captures with references; ScreenshotNeo captures live URLs through an API or MCP server.