Test X-Frame-Options and CSP frame-ancestors directives. Demonstrate clickjacking attacks and defenses.
This tool checks whether a page can be loaded inside an iframe and shows what stops it. Paste the X-Frame-Options and Content-Security-Policy header values from a page's response and it parses each directive - DENY, SAMEORIGIN, or the retired ALLOW-FROM syntax, plus frame-ancestors source lists - and flags anything obsolete or contradictory. It can also embed a URL live in an on-page iframe with a decoy click target, so you watch the browser itself allow or refuse the frame. The recurring surprise: ALLOW-FROM still turns up in header configs, but every current browser ignores it outright, leaving the page unprotected by that line alone.
A concrete input and expected output from the current implementation.
Input
X-Frame-Options: ALLOW-FROM https://partner.example.com
Expected output
Flagged as obsolete: modern browsers (Chrome, Firefox, Safari, Edge) ignore the ALLOW-FROM directive entirely and treat the header as if it were absent. This header provides no framing protection in any current browser. Replace it with a Content-Security-Policy frame-ancestors directive, e.g. frame-ancestors 'self' https://partner.example.com.
MDN's X-Frame-Options reference documents ALLOW-FROM as obsolete and states that current browsers no longer support it, so a page relying on it alone is framable by anyone.
Paste one or more response header lines - X-Frame-Options and/or Content-Security-Policy. The tool reads the X-Frame-Options value (DENY, SAMEORIGIN, or ALLOW-FROM) and any frame-ancestors source list, flags ALLOW-FROM as obsolete since modern browsers ignore it outright, and lists which origins the pasted policy would actually permit to frame the page.
Enter a URL and the tool renders it inside a real iframe on the page, with a decoy button overlaid on the invisible target to mimic a clickjacking overlay attack. Because cross-origin JavaScript cannot read another origin's response headers, this test relies on the browser's own frame-blocking enforcement rather than an inspected header - a blocked page simply renders blank.
No. A browser script can't read another origin's response headers unless that origin explicitly exposes them via CORS, which security headers never are. Paste the header value from your server config, curl -I, or your browser's network tab instead, and the tool evaluates that pasted text.
No - per MDN, modern browsers ignore ALLOW-FROM completely rather than falling back to it, so it adds no protection today. Use a CSP frame-ancestors directive for anything beyond same-origin framing; there's no current browser where ALLOW-FROM is the deciding factor.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Generate strong, random passwords with customizable length, character sets, and complexity requirements.
Analyze password strength with entropy scoring, crack-time estimates, and improvement suggestions.
Create cryptographically random strings for API keys, tokens, salts, and unique identifiers.
Create QR codes for URLs, text, Wi-Fi credentials, vCards, and more with customizable size and colors.
Scan and decode QR codes from uploaded images or your device camera to extract embedded data.
Compute MD5, SHA-1, SHA-256, and SHA-512 checksums to verify file integrity and detect tampering.