XSS 12 min read

XSS Payload Examples

XSS payload examples for authorized security testing. This page lists common payload types and test strings. Use only on systems you own or have permission to test. For detection methodology, see our XSS detection guide.

Run Free Scan

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

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

Basic XSS payloads (safe)

<script>alert(1)</script>
<img src=x onerror=alert(1)>
<svg onload=alert(1)>

Event handler variants

<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 learn to detect XSS?

See our XSS detection guide for step-by-step detection methods, context analysis, and prevention guidance.

Can I use these on any site?

No. Only on systems you own or have explicit permission to test. Unauthorized testing is illegal and can cause harm.

What tools automate XSS testing?

Vulnify's website vulnerability scanner includes XSS tests. OWASP ZAP, Burp Suite, and XSStrike also automate XSS detection for authorized use.