Check an HTML file. See what changed.

Try a real fix in three steps

1. Download the ZIP and checksums.

   The ZIP includes the standalone checker, source, README, and examples. The checksum file lists SHA-256 hashes for the ZIP and its files. Matching hashes verify those bytes; they are not a publisher signature or a security certification.

2. Extract it and open a terminal there.

   Use a trusted local disk and Node.js 22.13 or newer. You do not need to install dependencies or deploy an application.

3. Run the bundled example.

   node examples/run-demo.mjs

   The demo audits examples/before.html, where a search field has no label, and examples/after.html, where the label is fixed. It compares the improvement, then reintroduces the missing label to check regression detection.

   These are actual local checks, not a prerecorded result. Each run creates a new output folder named demo-results-<unique-id> and prints its location, so you can run it again without overwriting earlier reports. The demo exits 0 only when its checks pass, including the intentionally regressed comparison returning 1.

   A successful demo prints these results:

   Before: UI_ACCESSIBLE_NAMES = fail
   After adding a label: UI_ACCESSIBLE_NAMES = pass
   Fix comparison: exit 0; 0 new or worsened findings
   Removing the label again: exit 1; 1 new problem
   Runtime remains unknown.

Check your own export

Supply an HTML file you are authorized to inspect. Choose a non-sensitive app/page ID and keep that ID the same for subsequent exports of the same page.

# In the extracted checker folder, use your own exported HTML file.
node iswebmcp-offline.mjs audit ./export.html --app catalog-search --output ./baseline.json

# Make the fix in your app, then export its HTML again as current.html.
node iswebmcp-offline.mjs audit ./current.html --app catalog-search --output ./current.json
node iswebmcp-offline.mjs compare ./baseline.json ./current.json --output ./comparison.json

Reports are local JSON files. Existing output files are never overwritten: choose new filenames for later runs. Comparisons require the same app/page ID, evidence schema, model, and analysis limit, with a current report that does not predate the baseline. Hosted-scanner reports are a different format and cannot be used as an Offline Checker baseline.

The checker reports findings and recommendations; it does not automatically edit your app or apply fixes. Review and make changes in your own development workflow.

Know the boundary before using sensitive HTML

• Exported HTML only: nonempty UTF-8 files up to 2 MiB. Analysis runs in a worker with a 5-second time limit, a 128 MiB old-generation heap limit, and a 16 MiB young-generation limit. These are not a total process-memory cap or a filesystem-I/O deadline. If analysis exceeds a limit, it exits with an error rather than writing an incomplete report.
• No HTTP requests to public or private hosts, linked-asset fetching, page JavaScript execution, browser authentication, or SSO. URLs and UNC/device paths are refused as input paths.
• An export may omit runtime content, shadow DOM, or signed-in state. Complete coverage means these four checks ran on the supplied bytes, not that the file captures your whole app.
• The checker makes no application network calls or analytics requests. That is not an OS-level network-isolation guarantee: mapped, mounted, or synced filesystems and other software can move data. Use trusted local disks and OS-level egress controls when required.
• Reports omit raw HTML and input paths, but keep the app/page ID, a source hash, timestamp, and findings. Protect the exports and reports. A hash binds bytes; it does not anonymize them or verify their origin.