What is XSS (Cross-Site Scripting)?

Cross-Site Scripting (XSS) is a type of security vulnerability where an attacker injects malicious scripts into web pages viewed by other users. There are three main types: Reflected XSS (the payload is in the request), Stored XSS (the payload is saved on the server), and DOM-based XSS (the payload is executed via client-side scripts).

Why encode XSS payloads?

Encoding XSS payloads is a core penetration testing technique. Web applications often have input filters that block obvious payloads like . Encoding the payload in HTML entities, URL encoding, Unicode escapes, or Base64 can sometimes bypass these filters, revealing incomplete or misconfigured sanitization.

What is double encoding in XSS?

Double encoding means encoding a payload twice. For example, '<' becomes '<' with HTML entity encoding, then '<' with a second pass. Some vulnerable applications decode input twice before processing it, which can allow double-encoded payloads to bypass filters that only check once.

Is it legal to use this tool?

This tool is intended strictly for authorized security testing, penetration testing on systems you own or have explicit written permission to test, and security education. Using XSS techniques against systems without authorization is illegal in most jurisdictions and violates computer fraud laws. Always obtain written authorization before testing.

How do I prevent XSS in my application?

XSS prevention involves: output encoding (HTML-encode all user data before rendering), Content Security Policy (CSP) headers, using modern frameworks that auto-escape output (React, Angular, Vue), avoiding innerHTML with user data, using HTTPOnly and Secure flags on cookies, and validating/sanitizing all user input on the server side.

XSS Payload Encoder

Encode and decode XSS payloads for authorized security testing. HTML entities, URL, Base64, Unicode, hex, and double encoding.

For Authorized Security Testing Only Use this tool only on systems you own or have explicit written permission to test. Unauthorized XSS testing is illegal under the Computer Fraud and Abuse Act (CFAA) and equivalent laws worldwide.

Input Payload

Test Payloads (click to load):

Encoded Results

Enter a payload on the left to see all encodings.

Enter a payload to encode.

Understanding XSS Attack Types

Reflected XSS

The malicious script is included in a request (URL, form) and reflected back in the immediate response. The victim must click a crafted link. Not stored on the server.

Stored XSS

The payload is saved on the server (database, comment, profile) and executed whenever any user loads the affected page. More dangerous — no crafted link needed.

DOM-Based XSS

The vulnerability is in client-side JavaScript. The payload modifies the DOM without ever hitting the server. Common in innerHTML, document.write, and eval sinks.

How to Use the XSS Payload Encoder

Select a test payload from the quick-load chips, or type your own payload in the input area.
Choose Encode or Decode using the mode chips above the input.
Review all encodings — the tool produces HTML entity, URL, Base64, Unicode escape, hex escape, and double-encoded variants simultaneously.
Copy individual encodings using the Copy button on each row, then test them in your authorized target application.

Encoding Methods Explained

HTML Entities — Converts characters like < > & " to their HTML entity equivalents (< etc.). Useful for testing context-aware output encoding.
URL Encoding (percent encoding) — Converts characters to their %XX hexadecimal representation. Essential for payloads injected into URL parameters, query strings, or path segments.
Base64 — Encodes the payload as Base64. Used with eval(atob(...)) or data: URIs to bypass string-matching filters.
Unicode Escapes — Converts characters to \uXXXX notation. JavaScript interprets these natively, allowing script injection through Unicode-unaware filters.
Hex Escapes — Converts characters to \xXX hexadecimal notation, another form recognized by JavaScript engines.
Double Encoding — Applies URL encoding twice. Some vulnerable applications decode input twice (e.g., in a WAF and then in the application), allowing double-encoded payloads to slip through.

Common XSS Filter Bypass Techniques

Security researchers and penetration testers use encoding to test whether an application's input sanitization is complete. A well-implemented application should reject or neutralize all of these variants. If one encoding slips through, it indicates the application is only checking for specific patterns rather than performing proper context-aware output encoding. The gold standard for XSS prevention is to encode output at render time, not just validate input — because what constitutes "valid" depends entirely on the context where the data will be used.

When testing for XSS, always start with the simplest payload: <script>alert(1)</script>. If that fails, try event handlers like <img src=x onerror=alert(1)>. If those fail, try encoding variants. If all fail, the application is likely properly escaping output. Document every test and result for your penetration testing report.

Responsible Disclosure

If you discover a real XSS vulnerability during authorized testing, follow responsible disclosure practices: report the vulnerability privately to the organization's security team or via their bug bounty program (HackerOne, Bugcrowd, etc.), give them a reasonable remediation window (typically 90 days), and work collaboratively to verify the fix before public disclosure. Do not publish proof-of-concept exploits targeting real users without coordination. This protects both users and maintains the trust that makes bug bounty programs viable.

XSS Prevention Checklist for Developers

Use a modern framework (React, Angular, Vue) that auto-escapes template output
Never use innerHTML, document.write, or eval with user-supplied data
Implement a strict Content Security Policy (CSP) — Content-Security-Policy: default-src 'self'
Set HttpOnly and Secure flags on session cookies
Use the SameSite cookie attribute to mitigate CSRF alongside XSS
Validate input type/format on the server side — but rely on output encoding as the primary defense
Audit third-party scripts — any script on your page can steal user data

Frequently Asked Questions

Cross-Site Scripting (XSS) is a security vulnerability where attackers inject malicious scripts into web pages seen by other users. Types include Reflected (payload in URL), Stored (payload saved on server), and DOM-based (payload manipulates client-side DOM). XSS can steal session cookies, redirect users, deface pages, or silently execute actions on behalf of the victim.

Many web application firewalls (WAFs) and input filters block obvious XSS payloads. Encoding variants test whether the sanitization is thorough or only checks for specific literal strings. A properly secured application should neutralize all encoding variants because it encodes output at render time, regardless of what the input looked like.

Double encoding applies URL encoding twice — < becomes %3C then %253C. Some vulnerable systems (especially WAF + application combos) decode input twice: the WAF decodes once (sees %3C, still encoded), then the application decodes again (sees the raw <). This allows the payload to bypass the WAF's check.

This tool is legal to use for educational purposes, on systems you own, or on systems where you have explicit written authorization to test. Using XSS techniques against systems without authorization is a criminal offense under the CFAA (US), Computer Misuse Act (UK), and equivalent laws worldwide. Always get written permission before testing.

The primary defense is context-aware output encoding: HTML-encode data in HTML context, URL-encode in URL context, JavaScript-encode in script context. Use modern frameworks that auto-escape. Implement a Content Security Policy (CSP). Set HttpOnly and Secure cookie flags. Never use innerHTML with user data. Validate input on the server side as a secondary control.