What does 'script in alt text' actually mean?

You sent an email with an image, added alt text for accessibility, and suddenly it got blocked. Not because the image was broken. Not because of a typo. But because your alt text contained a script.

That’s not a bug. It’s by design. Email clients and security gateways block scripts in alt text because they can’t safely execute them — and if they can’t execute, they could still be malicious.

Alt text is meant to describe images for screen readers or when images fail to load. It’s not a code injection point. When you insert JavaScript or any executable code into alt text, you’re using a field meant for plain description as a potential exploit vector. That’s why even a simple script tag like <script>alert('test')</script> can trigger a block.

Key takeaways

  • Alt text in email images must contain only plain text; scripts are not allowed under any conditions.
  • Email gateways block any script-like content in alt text as a security measure, regardless of whether it’s technically harmful.
  • Even if the script is inert or meant for testing, its presence in alt text violates email security standards and can result in delivery failure.

Why do email filters block scripts in alt text?

Email security systems block any content that could execute code—even in embedded attributes like alt text. Filters assume that script-like syntax such as javascript:alert(1) in alt text is a deliberate attempt to trigger execution, regardless of your intent. Since the risk of delivering malicious payloads is too high, such content is treated as spam or abuse, leading to blocking or rejection by major providers.

How email filters detect and act on script-like patterns

Spam and security filters don't rely on intent—they scan for signatures that match known attack vectors. Even if you’re using alt text as a placeholder or for accessibility, strings resembling JavaScript (e.g. javascript:alert(1), onload=, or data: URLs) trigger a red flag. These patterns are common in phishing attempts, so filters treat them as dangerous by default.

Even harmless-looking code can cause issues. For example, javascript:void(0) may be used to prevent link behavior in HTML, but it still matches script patterns. Filters don’t parse code for “harmlessness”—they block anything that could be exploited, and alt text is not exempt.

Why the rule applies universally

There’s no safe way to verify that script-like syntax in alt text is benign at scale. Filters must err on the side of caution. The cost of a single compromised email is high—malware distribution, data theft, or reputation loss. So they assume the worst, even if you’re innocent.

This applies to all email infrastructure. Major providers like Gmail, Outlook, and Yahoo block messages containing such content regardless of sender reputation, domain, or intent. It’s not about trust—it’s about minimizing exposure to attack surfaces.

For context, the IETF’s RFC 8058 (which covers email security practices) outlines how filters prioritize preventing execution of untrusted code, especially in HTML attributes. While it doesn’t list alt text specifically, the principle applies broadly: any attribute that can load or execute code is considered risky.

Let’s be clear: you’re not at fault for using alt text with script syntax—especially if you copied code from elsewhere or worked with legacy templates. But the system doesn’t care. It only cares about risk. Fixing this means scrubbing all script-like strings from your email content before sending.

If you're unsure whether your campaign contains risky patterns, you can test it with a real inbox placement tool. MailTester’s inbox tester lets you send a sample email to real inboxes and see exactly how it’s treated. You’ll know instantly if script-like content in alt text triggered a block.

Test how your email lands in real inboxes—find deliverability issues before you send.

Does every script-like string in alt text trigger a block?

Not every script-like string in alt text triggers a block—only those that match known malicious patterns like javascript: or data: are flagged. A harmless typo like “jscode” won’t trigger a filter, but any recognized script syntax increases your risk of being blocked or marked as spam.

What patterns actually get flagged?

Spam filters and email security tools scan for valid script schemes. The javascript: protocol is a red flag because it’s commonly abused in phishing or XSS attacks. Similarly, data: URIs—especially those containing executable content—are frequently blocked. These patterns are defined in standards like RFC 2397, which describes the data URL scheme.

But not every variation of “js” or “script” triggers a block. A misspelled string such as “scrpt” or an inline code reference like “

Keep reading