Find invisible characters in JSON

Start with the value that looks normal

Imagine a release candidate with hundreds of dependency records. Each record has a package name, integrity hash, maintainer, registry, and sometimes a lifecycle script. One name contains a zero-width space. Another script path contains a right-to-left override. Neither problem needs to announce itself in an ordinary visual scan.

The risk is not limited to invalid JSON. These characters can be valid inside JSON strings, so a parser may accept the document while a reviewer, search, allowlist, or downstream tool sees something different from what the screen appears to show.

{
  "audit": {
    "source": "release-candidate/checkout-platform-8.14.0",
    "policy": "manual-review-before-production-promotion"
  },
  "dependencies": [
    {
      "package": "@commerce/checkout-\u200Bvalidator-038",
      "registry": "registry.corp.example",
      "integrity": "sha512-a81077c9488f1d38"
    },
    {
      "package": "@commerce/identity-runtime-093",
      "lifecycle": {
        "postinstall": "node scripts/verify-\u202Efdp.mjs"
      }
    }
  ]
}

Turn on visible security markers

Open Settings and enable Highlight risky invisible characters. This keeps the source data intact and changes how suspicious control, zero-width, bidirectional, and related characters are presented in the JSON viewport.

Return to the same record rather than searching for a different example. The useful comparison is the value before and after markers are enabled, with its package path still visible.

• Keep enough surrounding text visible to identify the affected field.
• Hover a marker to inspect the character label, Unicode code point, and severity.
• Check more than one finding; a dependency export may contain different classes of invisible characters.

Check the character, not just the spelling

A bidirectional control deserves a separate check because it can change the visual order of nearby text. In the audit fixture, the suspicious character sits inside a postinstall path. The marker tooltip identifies the code point even when the surrounding filename looks plausible at a glance.

Do not remove the character before you understand where the file came from. Preserve the original source or its hash, record the affected path, and compare the value with the trusted registry or lockfile.

Confirm the scope in Diagnostics

Open Diagnostics after inspecting individual values. The Security risk entry summarizes the marker count, affected bytes, and severity for the current source. It is a scope check, not a replacement for reviewing each affected field.

Use the count to make sure your spot checks are not the whole story. If Diagnostics reports three markers and you have reviewed only one, continue through the remaining paths before approving the source.

Decide what happens next

The right response depends on the source. A generated internal file may need an upstream serializer fix. A vendor package name may need to be rejected or compared with a trusted manifest. A user-entered label may be legitimate but still require normalization before it becomes an identifier.

Keep detection separate from remediation. Silent rewriting can destroy evidence or create a different value. If you sanitize data, make the rule explicit, retain the original input where policy allows, and rerun the same checks on the result.

• Compare the reviewed and sanitized versions

Know the boundary

Visible markers help a reviewer find suspicious Unicode and control characters. They do not prove that a file is malicious, certify that every string is safe, or replace package verification, schema checks, signatures, allowlists, and source-specific review.

Treat the feature as evidence for a decision. Confirm the exact code point, the affected field, the source of the document, and the behavior of the system that will consume it.