Redirect Masking Detection: See What's Really Happening Behind the Redirect

You click a link. The browser loads a page. Everything looks normal. But behind the scenes, you're not actually on the page you think you are - you're looking at it through an iframe, or a JavaScript redirect already fired, or a meta-refresh tag is about to bounce you somewhere else entirely.

This is redirect masking, and it's more common than you'd expect.

What Is Redirect Masking?

Standard redirect chains are transparent. You can see every hop - 301 here, 302 there, final destination at the end. HTTP-level redirects show up in response headers, and any redirect checker will catch them.

Masking is different. It happens after the page loads, inside the HTML itself. The server returns a 200 OK as if everything's fine, but the page content does something sneaky:

• Iframe wrapping - The page you see is actually loaded inside an iframe. The address bar shows one domain, but the content comes from another. Common in affiliate marketing when someone wants to keep their tracking domain visible while showing an offer page from a completely different site.
• Full-page iframes - A step further. A 100% width and height iframe with no border, covering the entire viewport. To the user, it looks like a normal page. It's not.
• Meta-refresh redirects - A <meta http-equiv="refresh"> tag in the HTML that redirects after a delay. Doesn't show up as an HTTP redirect because the initial response is a normal 200. Some use a 0-second delay to make it feel instant.
• JavaScript redirects - window.location, location.href, location.replace() - all achieve the same thing. The page loads, then JavaScript fires and sends you elsewhere. Often wrapped in obfuscation to make it harder to spot.
• Domain swaps - The page you land on is on a completely different domain than the one you clicked. Not a redirect per se, but a strong signal that something unexpected happened.

None of these show up in a standard HTTP redirect trace. You need to actually render the page and inspect what happens.

How We Detect It

The redirect checker already had a browser mode that uses a headless Chrome instance to follow redirects. We've now extended that to inspect the rendered page for masking signals.

When you run a check in browser mode, we now:

1. Follow the redirect chain as before (HTTP-level hops)
2. Wait for the page to fully load
3. Inspect the final page for iframes, meta-refresh tags, and JavaScript redirect patterns
4. Compare the final URL's domain against the starting URL's domain
5. Check for full-page iframes that cover the entire viewport

Each detected signal gets a severity rating. Domain changes and full-page iframes are flagged as high severity. Meta-refresh and JavaScript redirects are medium. Regular iframes that are large enough to display content (not just tracking pixels) are also flagged.

The results appear as a panel between the summary stats and the redirect chain details. If masking is detected, you get a warning with each signal listed. If nothing's found, you get a green "all clear" - which is useful confirmation in itself.

Why This Matters for Affiliates

If you run campaigns, you probably already know that affiliate links go through several hops. That's normal. What isn't normal is when the final destination uses masking to hide what's really going on.

A few scenarios where this helps:

• Vetting offers - Before sending traffic, check whether the offer page is actually the offer page or an iframe wrapper around something else. Some shady networks mask their landing pages to make them harder to copy or to hide the real domain.
• Debugging conversion issues - If conversions are tracking oddly, masking in the chain could be interfering with postback pixels or cookie paths.
• Compliance checks - Some traffic sources don't allow certain types of cloaking. Knowing whether a page uses masking before you run traffic to it saves you from policy violations.

Credit Where It's Due

This feature was inspired by code shared by Akahma from the affLIFT community. He'd built a standalone redirect tracking tool that included masking detection - checking for iframes, meta-refresh, JavaScript redirects, and domain changes.

We took that approach and integrated it into WebMon's browser-mode redirect checker, adapting it to work with our existing Browsershot service and adding severity ratings, size filtering for iframes (to ignore tracking pixels), and the UI panel to display results.

This is exactly the kind of thing that happens when you build tools alongside the people who use them. Someone spots a gap, shares an idea (or in this case, actual code), and it ends up benefiting everyone. So thanks, Akahma - this one's on you.

How to Use It

Head to the Redirect Checker, paste a URL, select Browser mode, and run the check. If any masking signals are detected, you'll see them in a yellow warning panel above the redirect chain.

Browser mode is the key - masking detection only works when we render the page in a real browser. The standard HTTP mode just follows headers, so it can't see what happens inside the HTML.

What It Won't Catch

Same honesty policy as always. This catches the common patterns - iframes, meta-refresh, window.location, and friends. It won't catch heavily obfuscated JavaScript that constructs a redirect in a way we don't pattern-match for, or server-side cloaking that serves different content based on your IP or user agent. Those are harder problems and we'll keep iterating.

For now, if you're vetting links or debugging redirect flows, this gives you a much clearer picture of what's actually happening after the page loads.

Try the redirect checker - select browser mode and paste any URL. Free, no account needed.