Explain-error preview
Paste a protected-output runtime error into the box below. The browser-side rule engine diagnoses the most likely JSO transform that caused it and recommends a concrete fix — identifier to exclude, option to toggle, file pattern to skip. No API key. No data leaves your browser. Same matchers the server-side /v1/ai/explain-error.ashx endpoint runs in preview mode.
1. Paste the error
2. Diagnosis
Rule-based local preview — same matchers as /v1/ai/explain-error.ashx when no provider key is configured. Provider-backed API calls can reason about novel errors the rules don't recognize; the rules stay on as the circuit-breaker fallback. Common patterns produce identical answers either way.
The four families of protected-output error
Every rule in the table above belongs to one of four families, and knowing which one you are in usually gets you to the fix faster than the specific message does.
- A name crossed a boundary. Something outside the protected code referenced a name by its original spelling — an inline HTML handler, a server response field, a stored key, a framework runtime symbol. This is the largest family by a wide margin. The fix is always an exclusion, never a rollback: identify the one name and reserve it. See the variable exclusion list and Protect Members.
- The environment rejected the output. A parser or a policy refused the file: an ES target older than the syntax you shipped, or a Content-Security-Policy that forbids the construct a transform emitted. Nothing is wrong with your code — the artifact and the environment disagree, and one of the two has to move.
- A guard fired on purpose. A domain lock, a date lock or a debugger trap did exactly what it was configured to do. The interesting question is not how to suppress it but whether the trip was expected. If it was not, the configuration is wrong; if it was, the message is being read by the person it was meant for.
- The pipeline shipped the wrong bytes. A path mismatch, an asset that did not travel with the protected output, or a source map that survived into the release. These are build-configuration problems wearing a runtime error as a disguise, and they are the ones most likely to be found by deployment hygiene checks rather than by debugging.
If you cannot place your error in one of the four, the fastest general technique is bisection over the option set: disable the aggressive transforms, confirm the error clears, then re-enable them one at a time. Whichever one brings the failure back is the one that needs an exclusion. Protect with a fixed seed while you do this — otherwise the output changes on every run and you cannot tell a fix from a coincidence.
How this composes
This preview is most useful paired with a production beacon. Wire your CDN to forward unhandled-error events at error from protected pages to a small webhook; the webhook calls explain-error server-side and posts the diagnosis into your incident channel. The full production-triage composition is documented at AIErrorRouting.aspx.
If your error doesn't match any rule, paste it into a support ticket — new rules get added based on what real customers hit. The bar is high-signal, not coverage: a rule that fires on one well-defined pattern beats a fuzzy rule that fires on three.
Frequently asked questions
What does this preview do with the error I paste?
It runs a rule engine in your browser against the message and matches it to the transform most likely to have produced it, then recommends a next step. Nothing is uploaded. The value is in narrowing the search: a protected-output error usually looks unfamiliar, and knowing which transform is implicated turns an open-ended investigation into checking one option.
What are the four families of protected-output error?
A name crossed a boundary, where something outside the protected code referenced a name by its original spelling. The environment rejected the output, where a parser or a policy refused the file. A guard fired on purpose, where a lock or a trap did exactly what it was configured to do. And the pipeline shipped the wrong bytes, where a path mismatch or a missing asset means the file running is not the file you meant to deploy. Placing your error in one of the four usually gets you to the fix faster than the specific message does.
Why does a name crossing a boundary fail at run time rather than during the build?
Because the two halves of the relationship are no longer visible to any single tool. The protected code renamed a definition; the reference lives somewhere the protector never saw, such as an inline handler in markup, a server response, or another bundle. Nothing in the build can compare them, so the mismatch surfaces the first time that code path executes. This is why an end-to-end run against the protected artifact catches so much more than a build does.
A guard fired. Does that mean something went wrong?
Not in the tool, no. It means a condition you configured was met, which is the guard working. The useful question is not how to stop the guard reporting but why the condition was true: a domain lock firing on a preview host, a date lock reached because the build is older than expected, or an integrity check tripped by an extension in the user's browser. Each of those has a different answer, and none of them is a defect in the transform.
What should I do when my error does not match any rule?
Bisect the option set. Disable the aggressive transforms, confirm the error disappears, then re-enable them in groups until it returns. That converges quickly and it works regardless of whether anyone has seen your particular message before. It is also worth sending the message to support, because the rule set grows from what customers actually hit and a high-signal rule that fires on one well-defined pattern is worth more than a fuzzy one.
How do I get production errors here in the first place?
Forward them. A small handler that reports unhandled errors from protected pages to an endpoint you control gives you the real messages from real browsers, which is the input this page is designed for. Pair it with the identifier map from the same build so that a trace can be turned back into something readable, since a protected stack trace is opaque to your own responders too.