XSS Payload Tester
Test XSS payloads against various sanitization techniques and encoding methods. Analyze payload effectiveness and learn about XSS prevention strategies. Essential for security testing and education.
Educational Purpose Only: This tool is designed for learning about XSS vulnerabilities and testing security measures. Never use these payloads on systems you don't own or have explicit permission to test.
Custom Payload Testing
Payload Library
Click any payload to load + analyze it. Sources: PortSwigger Web Security Academy, OWASP, HTML5 Security Cheatsheet.
Quick Security Best Practices
Show
- Always validate and sanitize user input on the server side
- Use Content Security Policy (CSP) headers to prevent inline script execution
- Encode output based on context (HTML, attribute, JavaScript, URL)
- Use modern frameworks with built-in XSS protection
- Regularly update dependencies and security patches
- Implement proper authentication and authorization
About XSS Payload Tester
A comprehensive XSS (Cross-Site Scripting) payload testing tool that helps security professionals and developers understand how different XSS attack vectors work and how various sanitization techniques defend against them. Test payloads against multiple encoding methods and see real-time analysis of their potential impact.
Why use a XSS Payload Tester?
Understanding XSS vulnerabilities is crucial for web security. This tool helps developers visualize how XSS payloads can be crafted and how different sanitization methods protect against them. It's an educational resource for learning about web security and a practical tool for testing input validation strategies.
Who is it for?
Perfect for security researchers studying XSS attack patterns, web developers implementing secure input handling, penetration testers validating security controls, and educators teaching web application security. Ideal for anyone wanting to understand XSS vulnerabilities and prevention techniques.
How to use the tool
Enter or select from predefined XSS payloads to test
Choose encoding and sanitization methods to apply
View how the payload is transformed by each security measure
Analyze the effectiveness of different protection strategies
Learn from detailed explanations of each payload type and defense mechanism
Frequently Asked Questions
What is XSS and how do I test for it?
Cross-Site Scripting (XSS) is an injection attack where malicious JavaScript runs in a victim's browser in the context of your site. Three main types: (1) Reflected XSS — payload comes in a URL parameter, immediately echoed back unsanitized. (2) Stored XSS — payload saved server-side (forum post, profile field), runs for every viewer. (3) DOM XSS — sink in client-side JavaScript (innerHTML = userInput) without server involvement. This tool exposes you to a curated library of XSS payloads across all three categories, plus polyglots (work in multiple contexts) and mXSS (mutation XSS via DOM parser quirks). Run them against your sanitization, CSP, and WAF to verify they catch what they should.
Is this tool legal to use?
Yes when used against systems you own or have explicit authorization to test. Legal contexts: testing your own production applications, sandbox/staging environments, CTF (Capture The Flag) challenges, authorized penetration test engagements (with signed Rules of Engagement), bug bounty programs (within the program's scope), educational labs. Illegal contexts: testing against any third-party website without written authorization, using payloads to actually exploit vulnerable production systems you don't own, attempting to bypass security controls on systems where you don't have authorization. Unauthorized testing violates computer-misuse laws in most jurisdictions (US: CFAA, UK: Computer Misuse Act, EU: Cybercrime Directive). When in doubt, get written authorization first.
How do I prevent XSS attacks?
Defense-in-depth across multiple layers: (1) Output encoding — escape user input based on the output context (HTML body, HTML attribute, JavaScript string, URL, CSS) using language-native libraries (OWASP Java Encoder, DOMPurify, html.escape). (2) Content Security Policy (CSP) — a HTTP response header that restricts which scripts can execute and from where; eliminates inline scripts and unsafe-eval. (3) HttpOnly cookies — prevents JavaScript from reading session cookies even if XSS succeeds. (4) Input validation — reject obviously-bad input at the boundary, not as the primary defense. (5) Framework defaults — React, Vue, Angular auto-escape by default; use {value} instead of dangerouslySetInnerHTML. The [User Input Sanitizer Tester](/tools/user-input-sanitizer-tester/) is the defensive companion to this offensive tool.
What's the difference between reflected, stored, and DOM XSS?
Reflected: payload travels in a URL or POST parameter, server echoes it back into the response without escaping. Victim clicks a crafted link; payload runs immediately. Defense: escape on output. Stored: payload saved on the server (database row — forum post, profile field, product review); runs for every visitor who loads the affected page. More dangerous because it's persistent. Defense: escape on output (NOT input — store raw, escape per context). DOM XSS: vulnerability lives entirely in client-side JavaScript — e.g., element.innerHTML = location.hash.slice(1). The server may be entirely innocent. Defense: avoid dangerous sinks (innerHTML, document.write, eval), use safe DOM APIs (textContent, setAttribute with allowlisted attributes).
What is Content Security Policy (CSP) and does it stop XSS?
CSP is an HTTP response header that tells the browser which scripts can run and where they can come from. Example: 'Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-abc123'' blocks all inline scripts except those carrying nonce='abc123'. A strict CSP stops most XSS even if an injection succeeds — the injected script lacks the nonce or fails the allowlist. CSP is not a silver bullet: misconfigured CSP (unsafe-inline, unsafe-eval, wildcard sources) provides little protection; CSP doesn't stop other injection types (HTML injection without script execution); and DOM XSS via specific sinks can bypass CSP. Test your CSP with this tool's payloads to find gaps.
What's a polyglot XSS payload?
A polyglot is an XSS payload crafted to execute in multiple contexts simultaneously. Famous example: `javascript:/*--></title></style></textarea></script></xmp><svg/onload='+/"/+/onmouseover=1/+/[*/[]/+alert(1)//'>` — works as an HTML body injection, in a script context, as an HTML attribute, AND as a URL parameter. Why: when you don't know the exact injection context, a polyglot maximizes the chance of execution somewhere. Defenders use polyglots to test multiple sanitization layers at once — if any layer leaks, the polyglot finds it. This tool includes several polyglots from the OWASP XSS Filter Evasion Cheat Sheet. Run them across all input vectors to identify which layer is weakest.
What is mutation XSS (mXSS)?
Mutation XSS exploits how browsers' DOM parsers re-interpret HTML during the innerHTML assignment process. Example: an attacker submits `<noscript><p title="</noscript><img src=x onerror=alert(1)>">` — looks safe to a server-side sanitizer (the dangerous payload is inside a title attribute), but when the browser parses it via innerHTML, it 'mutates' the DOM and the inner content becomes executable HTML. DOMPurify and modern sanitizers protect against known mXSS patterns, but new mutations are discovered periodically. Defense: use textContent or setAttribute instead of innerHTML where possible; if innerHTML is unavoidable, use a maintained sanitizer library (DOMPurify) and update it regularly.
How do I integrate XSS testing into CI/CD?
Three levels. (1) Static analysis — SAST tools (Semgrep, ESLint security plugins, SonarQube) catch obvious dangerous patterns (innerHTML assignments, dangerouslySetInnerHTML, unsanitized concatenation). Run on every PR. (2) Dynamic testing — DAST tools (OWASP ZAP, Burp Suite Enterprise) crawl staging environments and inject XSS payloads. Run nightly against deploy environments. (3) Specific regression tests — for known-XSS-vulnerable patterns in your app, write Cypress/Playwright tests that submit the payload and assert no alert() fires. This tool is for ad-hoc manual testing during development and incident response; for systematic coverage, integrate ZAP or Burp into your CI. Pair with the [User Input Sanitizer Tester](/tools/user-input-sanitizer-tester/) for defensive testing.
Share This Tool
Found this tool helpful? Share it with others who might benefit from it!
💡 Help others discover useful tools! Sharing helps us keep these tools free and accessible to everyone.