The email arrives at 6:14 a.m. A researcher has a stored XSS in your support form. The payload is not a clever polyglot, it is not a mutation XSS bypass, it is not even an event handler on an unusual tag. It is <img src=x onerror=alert(1)> sitting in the subject field, rendered raw into an admin-only ticket view. The bug is in the input layer, and the input layer is the layer nobody stress-tested. The XSS Payload Detector is the kind of tool you wish you had run on that field before the email arrived.
What a focused XSS detector actually checks
A real XSS check is not one regex. It is a small library of patterns, each targeting a different sink, with the detector telling you which one fired and why. The categories that matter in 2026 are tag-injection vectors (any string that introduces a new HTML element into a context that should not allow it), event-handler vectors (anything from onerror through onpointerover, including the modern onfocus and ontransitionend variants), javascript: and data:text/html URL vectors, attribute-breakout vectors (the old " onmouseover=... pattern that still appears in junior-written templates), and the SVG and MathML exotic-tag vectors that the browser parsers accept but the auditor’s mental model does not. A detector that only looks for <script> misses most of these. A detector that returns a verdict plus the category lets you triage.
The practical shape of the result matters. Vulnerable: tag-injection via img onerror is actionable. Suspicious is not. When you wire a detector into a pre-commit hook or a CI job, you need the verdict to be a clear yes or no, with the specific reason attached so the developer can fix the right thing.
Where XSS actually slips through in 2026
The classic 2010-era vector <script>alert(1)</script> is the one every framework sanitizes by default. The vectors that still ship to production are the boring ones: rich-text fields that allow <img> for avatars but do not strip onerror attributes, search boxes that reflect the query into a title= attribute without HTML-encoding the quote character, error pages that print the requested path into a <pre> block and forget that <pre> still parses HTML, and the always-popular case of pasting user content into a Markdown renderer that allows raw HTML pass-through. Each of these is a one-line fix at write time, and each is invisible to a code reviewer without a tool.
The XSS Payload Detector is built for the boring cases. You paste the string, you get the verdict. It is fast enough that you can run it on every form input in a regression suite, and the result is structured enough that you can wire it into a gate.
Running a detector against the strings that ship
The most useful test you can run today is the last ten support tickets from the last week, exactly as they are stored in the database, run through the detector as if they were the body of a new ticket view. If any of them fire, the bug is in the sanitizer or in the renderer, and the fix is the same regardless of which one. You will find, in most codebases, that two or three of them do fire. Those are the inputs that produced the email at 6:14 a.m.
The second useful test is the negative one. Take the strings that the detector flags, sanitize them through your existing output encoding, and re-run them. If they no longer fire, the output layer is doing its job and the input is the problem. If they still fire, the output layer is the problem and the fix is there. Either way you have a specific file and a specific line to change, which is what an audit needs to be useful.
What a detector is not
An XSS detector is not a substitute for a Content Security Policy. A detector is not a substitute for output encoding. A detector is not a substitute for the framework’s built-in escaping. A detector is the tripwire that catches the case where the other three were forgotten, the tripwire that fires in CI, the tripwire that prevents the email at 6:14 a.m. Use it on every form input, use it on every rich-text paste, use it on every URL parameter that gets reflected into HTML, and let it be the layer that catches the regression when someone removes a sanitization call six months from now.
Most reflected XSS does not get past a black-box scanner because it is sophisticated. It gets past because nobody ran the obvious detection against the obvious string. A focused detector that returns a verdict with a per-vector reason, in under a second, beats every regex that lives in your CI today. Run your last ten reports through the XSS Payload Detector, fix the ones it flags, and then keep the detector as a pre-commit hook. The category of bug is not going away; the time to find it is. Open the XSS Payload Detector and run it on the next form input you ship.
Explore more security and validation tools at elysiatools.com.
