How to Fix Happo Screenshot Mismatches on Indian Language Websites

A Happo diff tells you that captured pixels changed; it does not tell you why. For Indian-language text, first check whether the difference repeats, then inspect font delivery and fallback, text integrity and shaping, browser and viewport settings, and only then consider a narrowly chosen visual-diff tolerance. Do not assume every mismatch is an Indian-language rendering defect.

This workflow is useful for text in scripts such as Devanagari, Bengali, Tamil, Telugu, Kannada, Malayalam, Gujarati, Gurmukhi, Odia and Urdu. The exact cause still depends on your page, font files and capture environment. Happo documents browser targets, viewport configuration, waiting for fonts and asynchronous assets, animation silencing, color-delta tolerance and screenshot retries. See the Happo documentation for the configuration supported by your integration.

1. Locate and classify the mismatch

Open the before, after and diff views for the failed capture. Record the story or page state, target browser and viewport. Inspect the changed region itself instead of treating a red status as a diagnosis.

What changed	Investigate first
One or more characters are missing or replaced	Font request failures, glyph coverage, fallback family and the exact text passed to the page.
Glyph shapes differ but wrapping and geometry match	Resolved font face, browser target and shaping/rendering environment.
Words wrap differently or lines shift	Font metrics, font weight, viewport width, CSS and fallback behavior.
Text baseline or line height moves	Font load timing, selected face, line-height and browser differences.
Many unrelated pixels change slightly	Capture repeatability, animation, asynchronous assets and small rasterization noise.
The whole component or page shifts	Viewport, responsive state, content state or a real layout change.

2. Check repeatability before changing the baseline

Retry the affected capture or run just the failing screenshot again if your Happo workflow supports it. Compare the repeated result with the original baseline and the failed run.

If the diff disappears or moves, investigate unsettled fonts, images, async content, animation and other changing page state.
If the same glyphs and geometry differ each time, prioritize font selection, text content, browser target and layout.
If many pages fail together after a shared change, check shared font assets, global CSS and the baseline update.

Do not accept a new baseline until you have decided whether the new rendering is intended. A stable diff can still be a genuine regression.

3. Make the capture inputs comparable

Compare the same page or story, text sample, application state, viewport and browser target. A different responsive breakpoint or browser can change both font selection and layout. If your configured suite covers more than one browser, compare the same case across targets to see whether the issue is target-specific or shared.

Happo’s current project configuration and supported target details can vary by integration and version. Use its current documentation rather than copying an old config blindly. The repository’s current README shows the general configuration shape below: credentials, targets and a viewport on each desktop target.

import { defineConfig } from 'happo';

export default defineConfig({
  apiKey: process.env.HAPPO_API_KEY!,
  apiSecret: process.env.HAPPO_API_SECRET!,
  targets: {
    'chrome-desktop': {
      type: 'chrome',
      viewport: '1280x720',
    },
    'firefox-desktop': {
      type: 'firefox',
      viewport: '1280x720',
    },
  },
});

This is a minimal target example, not a complete application integration. Keep credentials in environment variables, and use the target names and options documented for your installed Happo release. The Happo repository documents the current package and links to the full documentation.

4. Verify font loading and fallback

A screenshot can capture fallback text if the intended face has not loaded or cannot be used. Happo’s integration material describes waiting for fonts and asynchronous assets, but verify your actual requests and computed styles when glyphs do not match.

In the captured page’s browser developer tools, inspect Network and filter for font requests. Check that the expected file is requested and succeeds.
Inspect computed styles for the text element. Confirm the intended font-family, weight and style are applied, and look for a fallback face.
Check the CSS font-face declaration and asset URL for the exact weight used by the component. A regular face does not guarantee that a separately requested bold face loaded.
Confirm that the face includes the characters in the failing sample. Test a short string containing the affected characters, not only Latin text.
Compare the Happo result with a local browser as a diagnostic clue. A local match does not prove that the capture worker uses identical font files or platform configuration.

If the font is served from another origin, inspect the browser’s request result and console for access or loading errors. Fix the font delivery or font-family configuration at its source; adding arbitrary letter spacing can mask the symptom while damaging text.

5. Check text integrity and shaping

Indic-script text can use combining marks and sequences that must be processed together. OpenType, ICU and HarfBuzz are relevant technologies in the broader Indian-language localization context, but that context does not establish a Happo-specific shaping defect or identify the cause of a particular diff.

Build a minimal reproduction with the exact failing text and CSS.
Compare the source string with the rendered input. Check for truncation, escaping mistakes or transformations that alter the sequence.
Preserve combining marks and conjunct-forming sequences exactly. Do not normalize, reorder or edit the sample as a way to make a baseline pass unless that transformation is part of the intended application behavior.
Use the same font file, weight and browser target when comparing the reproduction.

If the minimal sample renders correctly while the component does not, investigate component CSS, content transformations and the application’s state rather than changing the test tolerance.

6. Isolate browser and viewport differences

Run the same state at the same viewport in another configured browser target. Happo documents desktop and mobile browser targets, including Chrome, Firefox, Edge, Safari and iOS Safari in its material; the currently available options depend on the product configuration.

Only one target differs: inspect that target’s font and browser environment and confirm the intended target configuration.
All targets differ in the same way: check shared application code, text, font assets and baseline changes.
Only a narrow viewport differs: inspect responsive CSS, line wrapping and whether the font changes at a breakpoint.

Keep target and viewport comparisons controlled: change one axis at a time. Otherwise, a changed browser and changed viewport can produce a diff whose cause is hard to separate.

7. Stabilize asynchronous content and animation

Wait for the page’s relevant content to settle before capture. Happo describes waiting for fonts and asynchronous assets and provides animation silencing. Use the mechanism available in your integration, and make the capture state deterministic where possible.

Ensure the component is in the intended state before the screenshot is taken.
Check for late font swaps, images, data or other content that can move text after initial rendering.
Silence animations for visual regression captures when motion is not what the test is intended to validate.
Avoid adding a long arbitrary delay as the only fix. A delay can slow every run and still fail when an asset takes longer than expected.

8. Tune visual tolerance only after diagnosis

Happo’s color-delta tolerance can reduce small pixel differences such as anti-aliasing or compression noise. First inspect the diff and decide that the remaining changes are minor raster noise. Apply a narrow tolerance appropriate to that reviewed case and continue reviewing highlighted changes.

Do not use tolerance to hide missing glyphs, a different font, incorrect shaping, line-wrap changes or layout shifts. Those are meaningful visual changes even if a broader threshold makes the suite pass.

9. Troubleshooting common failures

Symptom	Likely cause	Fix
Text is correct locally but absent or different in Happo	The intended font did not load in the capture, or the worker selected fallback.	Inspect the font request and computed family in the captured page; verify the asset path, face and weight.
Only some characters are wrong	The chosen face may not cover those characters, or the input sequence changed.	Check coverage and compare the exact source string in a minimal reproduction.
Text changes between retries	Font swap, asynchronous page state, animation or other non-deterministic rendering.	Wait for the relevant assets/state, silence unrelated animation and retry the one screenshot.
One browser target differs	Target-specific browser or font rendering behavior.	Compare identical text and viewport across targets; verify that the affected target is expected.
Text wraps differently on mobile	Viewport or responsive style differs, or font metrics changed.	Match viewport dimensions and inspect breakpoints, font face, size and line-height.
Diff is widespread but low contrast	Small rasterization differences or unstable assets.	First stabilize capture and review the changed areas; only then consider a narrow color-delta tolerance.
Happo config rejects a target or option	Configuration copied from a different package version or integration.	Check the current Happo documentation for the installed release and use its supported target and option names.
A retry passes but the original run failed	The capture may have been spurious, but one passing retry does not prove the page is correct.	Inspect both results, retry the individual screenshot if available and check for intermittent loading before accepting.

10. Keep screenshot runs reliable and efficient

Fix shared causes centrally: a font-delivery or global CSS issue can affect many stories; correct the common source instead of weakening each comparison.
Keep test inputs fixed: consistent text, state, viewport and target make later regressions easier to understand.
Retry selectively: use a single-screenshot retry for a suspected spurious result where available, rather than treating all failures as transient.
Use tolerance sparingly: broader tolerance can reduce sensitivity to real text or layout changes.
Account for the cost of waiting: waiting for assets improves capture consistency, while unnecessary delays increase CI time. Prefer a meaningful readiness condition supported by your integration.

The dossier does not provide a measured failure rate, runtime benchmark or Happo cost figure for this problem, so none should be inferred from these recommendations.

Or skip the browser setup

If you need a clean screenshot of a page while investigating its rendered output, ScreenshotNeo is a website screenshot API and MCP server. It does not replace Happo’s baseline comparison, but it can capture a page without setting up browser automation. 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

Cookie banners are accepted like a visitor and removed before the shot, along with supported newsletter popups and chat widgets; each cleanup step can be turned off. Bot checks, blank pages and failed loads are never billed, and the response identifies the page verdict and billing status. AI agents can use its MCP server tools for screenshots, page information and PDF capture. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots.

FAQ

Does a Happo diff mean the font is broken?

No. It identifies a visual change. Inspect the changed region and check repeatability, loading, font selection, text integrity, target and viewport before deciding on a cause.

Should I update the baseline after a font change?

Only after reviewing the rendered result and confirming that the new appearance is intended across the relevant targets and viewports.

Should I compare Indian-language text in every browser?

Compare the targets that your product supports and your Happo suite configures. Testing multiple targets helps distinguish a target-specific rendering difference from a shared application change.

Can a pixel tolerance fix incorrect glyphs?

It can suppress differences from the comparison, but it does not correct the font, text or layout. Diagnose those first.